harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject Re: Platform dependent code placement (was: Re: repo layout again)
Date Fri, 10 Mar 2006 20:48:29 GMT
On 3/9/06, Oliver Deakin <oliver.deakin@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 <mark.hindess@googlemail.com>
IBM Java Technology Centre, UK.

Mime
View raw message