"Mark Hindess" <[EMAIL PROTECTED]> 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.
