On 22/02/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
>
> On 2/23/06, Matt Benson <[EMAIL PROTECTED]> wrote:
> >
> > Are these just sample names? Could there be
> > shared/foo_linux.c
> > whatever/bar_linux.c
> > foo_ia32/bar.c
> > bar_linux/baz.c
> > baz_linux_ia32/more.c
>
> Yes, they could. The pattern for identifying architecture or OS
> dependence for a file is like [\W_]${attr}[\W_] where ${attr} stands
> for either specific OS or architecture.> > If so, will a directory always have no more than one > > "leading name", i.e. not OS or architecture? > > 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. 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. For example, defining properties for concepts like "os provides a getcwd" function, "os provides a clock_gettime function", "processor provides a fast implementation of a quuxo operation", etc. Third, fixing my second problem means we end up implementing autoconf (and associate tools) in ant. We might also end up having to implement new versions of code management tools so that people can find the right bit of code to edit. Fourth, if we don't use conventional tools and appropriate, meaningful code layout, then we will be raising the bar significantly for new developers considering contributing to the project. Regards, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
