You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Oliver Deakin <ol...@googlemail.com> on 2006/03/09 14:50:06 UTC
Re: Platform dependent code placement (was: Re: repo layout again)
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/%3c6928c5160602151329r7e0c0420ib6c8aaccfba3a8f5@mail.gmail.com%3e
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3cOF8F1D09F4.2B645AF4-ON85257123.00704C90-85257123.00744922@ca.ibm.com%3e
[3]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c8ce6aa550602211230g480ef50l48ee2b3d1991b8bf@mail.gmail.com%3e
Re: Platform dependent code placement (was: Re: repo layout again)
Posted by Mark Hindess <ma...@googlemail.com>.
On 3/9/06, Oliver Deakin <ol...@googlemail.com> wrote:
> Time to resurrect this thread again :)
We'll have to try to kill it properly this time. ;-)
> 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.
Wont some modules have another level after native? Since there are
currently more sub-directories in native-src/linux.iA32 and
native-src/win.IA32 than there are modules?
> 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.
I don't think we should worry so much. I think we should simply make
it as complicated as it needs to be for what we have today and let it
evolve when a clear requirement to change comes along. That means for
today, we might just have:
linux
windows
shared
We shouldn't even split by arch until we know we have too - most of
the current code should be usable on most architectures without
changes or at least easily fixable without duplicating entire files.
(Thread .asm/.s files being an exception.)
We can decide what to do when something concrete comes up. If nothing
else it is much easier to reason about a concrete example, than trying
to beat an issue to death when we are all probably envisioning
different future 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!).
I prefer the use of make because it's what C coders are going to be
most familiar with and I don't want to raise the bar for
contributions.
I'm happy to postpone the use of VPATH until we really need it.
Although GNU make does make life a little easier - its richer function
support allows definitions to be derived from others and avoid
duplication - I think we can stick with nmake until the moves are
complete. Trying to change to GNU make and moving at the same time
probably just makes it a little harder.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.