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 ([EMAIL PROTECTED])
>>>>> IBM Java technology centre, UK.
>>>>
>>>>
>>>> Dan Lydick
>>>>
>> --
>>
>> Tim Ellison ([EMAIL PROTECTED])
>> IBM Java technology centre, UK.
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
