harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Johnson <Graeme_John...@ca.ibm.com>
Subject Re: Platform dependent code placement (was: Re: repo layout again)
Date Tue, 28 Feb 2006 21:10:09 GMT
"Mark Hindess" <mark.hindess@googlemail.com> wrote on 02/23/2006 04:06:16 
AM:
<snip>
> > I'd suggest that file is considered platform dependent if it contains
> > any of "magic" platform keywords (like ia32, linux, e.t.c.) in it's
> > full name. Directory name may or may not contain a "leading name". For
> > example, file */linux/*.c should be considered as linux specific as
> > well. Another example, file */*_linux_solaris_*/*.c is considered as
> > shared between linux and solaris, but not applicable for win, e.t.c.
> 
> I have a few concerns about this plan.
> 
> First, that we'll end up renaming relatively simple file names like
> foo_linux_solaris.c to unmanageable things like
> foo_linux_solaris_aix_plan9_freebsd_osx_openbsd_ecos.c.
<snip>

Andrey's earlier statement about allowing the component to choose the 
names for specializations sounds exactly right.  If you're developing the 
JIT you would want to split along processor lines (e.g. /ia32 /ppc) 
whereas the file-system interface will likely follow operating-system 
lines (e.g. /win32, /linux, /posix).

I'm not convinced about embedding the axis of specialization (OS/ARCH)
in filenames.  It seems like a every new component that comes along could 
demand a token in the filename.

Based on our experience with J9 we've also seen real value in keeping file 

names consistent (e.g function foo() lives in file bar.c).  This helps 
developers form a mental map of where a given piece of functionality 
resides, and ultimately makes navigating a large codebase easier.

For example, if a function hyfile_open() is always defined in the hyfile.c 

then your task is simply navigating to the correct version of hyfile.c in 
the directory tree.  If you play tricks with the filename by appending 
suffixes, you become more dependent on external tools like grep or ctags 
to locate the right file. 

My vote is for consistent file names, in directories whose names are
selected by the component owner.  A list of 'blessed' OS and ARCH values
would go a long way to helping component owners select the right directory
name.

<snip> 
> Second, if we define everything in terms of high level concepts, such
> as os and arch, then we will be losing the important information about
> the real distinction.  This would make it harder for new developers to
> understand the choices and reasoning embodied in the code.  To avoid
> this, we should really be defining (and using) the actual concept that
> is important in making the distinction about which code to pick up.
<snip>

Regardless of where you start defining configuration flags (OS and ARCH
seem like a good start to me) a few simple techniques can make your life
easier:

   i) Choose names that are unlikely to conflict with system headers by 
      adopting a suitable prefix. For example if you like: HY_ARCH or 
      HY_OS, your code would read like:

        #define HY_ARCH_IA32   1
        #define HY_OS_LINUX    1        /* this flag is turned on */
        #define HY_OS_WIN32    0        /* this flag is turned off */

  ii) Produce a list of the blessed names, and the pattern for declaring 
      new ones.  This helps anyone new to the project understand what
      exists already.
 
  iIi) Consider using #define with values (either one or zero) so that 
      you can use #if tests in the code.  We've found this is slightly 
      cleaner than the #ifdef(FLAGX) or defined(FLAGX) flavours. 
      For example: 

        #if HY_ARCH_IA32 && HY_OS_LINUX
            /* do something */
        #else
            /* do something else */
        #endif

my $0.02

Graeme Johnson
J9 VM Team, IBM Canada.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message