Time to resurrect this thread again :)
With the work that Mark and I have been doing in HARMONY-183/155/144/171
we will be at a point soon where all the shared code has been taken out
of the native-src/win.IA32 and native-src/linux.IA32 directories and
combined into native-src/shared. Once completed we will be in a good
position to reorganise the code into whatever layout we choose, and
refactor the makefiles/scripts to use gmake/ant across both platforms. I
dont think previous posts on this thread really reached a conclusion, so
Ill reiterate the previous suggestions:
1) Hierarchy of source - two suggestions put forward so far:
- Keep architecture and OS names solely confined to directory names.
So, for example, we could have:
src\main\native\
shared\
unix\
windows\
windows_x86\
solaris_x86\
All windows_x86 specific code will be contained under that
directory, any generic windows code will be under windows\, and code
common to all
platforms will be under shared\ (or whatever name).
So when looking for a source/header file on, for example, windows
x86 the compiler would first look in windows_x86, then windows, then common.
- Alternatively, have directory names as above, but also allow the
OS and arch to be mixed into file names. To quote Andreys previous mail [1]:
"Files in the source tree are selected for compilation based on
the OS or ARCH attribute values which may (or may not appear) in a file
or directory name.
Some examples are:
src\main\native\solaris\foo.cpp
means file is applicable for whatever system running Solaris;
src\main\native\win\foo_ia32.cpp
file is applicable only for Windows / IA32;
src\main\native\foo_ia32_em64t.cpp
file can be compiled for whatever OS on either IA32 or EM64T
architecture, but nothing else."
Files will be selected using a regex expression involving the OS
and arch descriptors. This is intended to cut down duplication between
source directories.
Personally I prefer the first system as it is simple to maintain, keeps
file names consistent and concise and allows developers to easily keep
track of function location.
For example, as Graeme pointed out in [2], the developer will always
know that hyfile_open() is defined in hyfile.c.
In addition, I don't believe that the second system will give us much of
a decrease in the number of duplicated files. For example, if a piece of
code is unique to only linux
and windows on x86, will the file be named foo_linux_windows_x86.c? How
will the build scripts be able to determine whether this means all linux
platforms plus
windows_x86 or windows and linux only on x86? In these cases we will
either end up duplicating foo_x86.c in the windows and linux directories
or creating an extra directory
called x86 which contains foo_windows_linux.c. Potentially we will
either get similar amounts of duplication, or more directories than the
first method, and because there
is no hard rule on the layout (you can choose directory or filenames to
include OS/arch) there is no guarantee where a developer will choose to
put their code in these situations.
2) Build tools - there have been two previous suggestions:
- Use gmake and VPATH to complement the first layout described
above. This could lead to platform independent makefiles stored in the
shared\ directory of each module
that include platform specifics (such as build file lists,
compiler flags etc) from a centralised set of resources.
- Alternatively, use Ant to select the set of files to be compiled
by employing regex expressions. This sits well with the second layout
described above (although could also
be applied to the first) and a regex expression has been described
by Nikolay in [3].
I prefer the use of gmake here. We can use generic makefiles across
platforms and pointing the compiler at the right files in the first
layout above is as easy as setting VPATH to, for example,
windows_x86:windows:shared. I think that complex regex expressions will
be harder to maintain (and initially understand!).
Opinions? Once we agree on ideas, perhaps we could put together a
Wiki/website(?) page describing layout, tools and a list of OS/arch
names to use.
Oliver Deakin
IBM United Kingdom Limited
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED]
[3]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED]
