harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject Re: Platform dependent code placement (was: Re: repo layout again)
Date Thu, 23 Feb 2006 09:06:16 GMT
On 22/02/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> On 2/23/06, Matt Benson <gudnabrsam@yahoo.com> 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

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.


Mark Hindess <mark.hindess@googlemail.com>
IBM Java Technology Centre, UK.

View raw message