Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor
 denied by domain of t.p.ellison@gmail.com)
Message-ID: <43F60429.9020208@gmail.com>
Date: Fri, 17 Feb 2006 17:13:13 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Platform dependent code placement (was: Re: repo layout again)
References: <6928c5160602151329r7e0c0420ib6c8aaccfba3a8f5@mail.gmail.com>
	 <43F5D3D9.2000408@gmail.com>
 <6928c5160602170821g35312d39ie8449b5ad21ac2bc@mail.gmail.com>
In-Reply-To: <6928c5160602170821g35312d39ie8449b5ad21ac2bc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Andrey Chernyshev wrote:
>>> 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, ...

Ah, I see.  I hadn't appreciated that you can mix-n-match the dir names
and file names encoding.

> 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.

do you have any examples (i.e. snippets of a non-trivial Ant script)
that show what it would end up like?  I'm trying to figure out in my own
head whether it would be a few general regex selectors, or a load of
them!  I think you may be do it with just a few, right?

Regards,
Tim

>> 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.
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.