harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Chernyshev <a.y.chernys...@gmail.com>
Subject Re: Platform dependent code placement (was: Re: repo layout again)
Date Fri, 17 Feb 2006 16:21:05 GMT
> > src\main\native\win\foo_ia32.cpp
> >     - file is applicable only for  Windows / IA32;
>
> why has the ARCH flipped onto the file name?  why not win_ia32 ?

Well, let's see - if I have a file which is shared between Windows and
Linux, but it is IA32 specific, then I'll have to duplicate it in
win_ia32 and linux_ia32 dirs. It means having both ARCH and OS in a
file name isn't always convenient.

Another case, if I have only one file in my component which is
IA32-specific, it could be more convenient just to rename it like
foo.c -> foo_ia32.c and keep it at the same location, rather than move
to some other directory. One sort of problems coming here is that
every additional directory may need to be registered appropriately as
a source search path in development / debugging tools (you'd face this
if you try to debug with MSVC, for example). I just thought that
giving a freedom to choose between naming files or directories will
help people to work in the most convenient way.

>
> > src\main\native\foo_ia32_em64t.cpp
> >     - file can be compiled for whatever OS on either IA32 or EM64T
> > architecture, but nothing else.
>
> I agree with the approach, but left wondering why it is not something like:
>   src\main\native\
>                   common\
>                   unix\
>                   windows\
>                   zos\
>                   solaris\
>                   solaris_x86\
>                   solaris_sparc\
>                   windows_ifp\
>
> i.e. a taxonomy covering families of code (common, unix-like,
> windows-like) and increasingly specific discriminators.

Well, this directory structure does fit to the scheme I proposed, it
is a particular case of it.  Some people probably will want also to
play with the file names within a single directory in the same style: 
foo_solaris.c, foo_solaris_sparc.c, ...
I guess if  a component contains only 3 platform dependent c files,
someone would be frustrated to create 3 different directories for
them.

>
> > The formal file selection rule may look like:
> >
> > (1) File is applicable for the given OS value if its pathname contains regexp
> > [\W_]${OS}[\W_], or pathname doesn't contain any OS value;
> >
> > (2) File is applicable for the given ARCH value if its pathname contains regexp
> > [\W_]${ARCH}[\W_], or pathname doesn't contain any ARCH value;
> >
> > (3) File is selected for a compilation if it satisfies both (1) and
> > (2) criteria.
>
> If we restrict the OS and ARCH identifiers to directories then it will
> allow us to use the gmake VPATH functionality to select the right file,
> so compiling on solaris x86 will have a
> VPATH='solaris_x86:solaris:unix:common' and so on.

I see. Possibly vpath (small letters) could address the filenames?
Perhaps something like this should work:
vpath %solaris%.c
vpath %.c  soalris:unix:common

> I like the idea -- if we agree to use gmake throughout then I think we
> get this functionality 'for free'.

I guess the same could be done relatively easy for Ant as well, with
help of filesets and <containsregex> selectors.

> Using the names consistently will definitely help, but choosing whether
> to create a separate copy of the file in a platform-specific
> sub-directory, or to use #define's within a file in a shared-family
> sub-directory will likely come down to a case by case decision.  For
> example, 32-bit vs. 64-bit code may be conveniently #ifdef'ed in some .c
> files, but a .h file that defines pointer types etc. may need different
> versions of the entire file to keep things readable.

Yes, I agree. This is why I suggest to keep both selection mechanisms
- sometimes #define is more efficient, and sometimes dir/filename is
much more clear.

>
> > Finally, I'd suggest that the platform dependent code can be organized
> > in 3 different ways:
> >
> > (1) Explicitly, via defining the appropriate file list. For example,
> > Ant xml file may choose either one or another fileset, depending on
> > the current OS and ARCH property values. This approach is most
> > convenient, for example,  whenever a third-party code is compiled or
> > the file names could not be changed for some reason.
>
> Ant ?!  ;-)  or platform-specific makefile #includes?

Let's consider both for now :)

>
> There will be files that it makes sense to share for sure (like vmi.h
> and jni.h etc.) but they should be stable-API types that can be
> refreshed across the boundary as required if necessary.

Agreed. I think it would be great if  we can keep our inter-component
interfaces (like vmi.h) platform independent.


Thank you,
Andrey Chernyshev
Intel Middleware Products Division


>
> > Hence, the most efficient (in terms of code
> > sharing and readability) code placement would require a maximum
> > flexibility, though preserving some well-defined rules. The scheme
> > based on file dir/name matching seems to be flexible enough.
> >
> > How does the above proposal sound?
>
> Cool, perhaps we can discuss if it should be gmake + vpath or ant.
>
> Thanks for resurrecting this thread.
>
> Regards,
> Tim
>
>
> >>> Maybe in some components we would want to include a window manager
> >>> family too, though let's cross that bridge...
> >>>
> >>> I had a quick hunt round for a recognized standard or convention for OS
> >>> and CPU family names, but it seems there are enough subtle differences
> >>> around that we should just define them for ourselves.
> >>>
> >> My VM's config script maintains CPU type, OS name, and word size as three
> >> independent values.  These are combined in various ways in the source code
> >> and support scripts depending on the particular need.  The distribution script
> >> names the 'tar' files for the binaries with all three as a part of the file
name
> >> as, "...-CPU-OS-WORD.tar" as the tail end of the file name.  (NB:  I am going
> >> to simplify the distribution scripts shortly into a single script that creates
the
> >> various pieces, binaries, source, and documentation.  This will be out soon.)
> >>
> >> Does this help?
> >>
> >> Dan Lydick
> >>
> >>> Regards,
> >>> Tim
> >>>
> >>>
> >>> --
> >>>
> >>> Tim Ellison (t.p.ellison@gmail.com)
> >>> IBM Java technology centre, UK.
> >>
> >>
> >>
> >> Dan Lydick
> >>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>

Mime
View raw message