harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Platform dependent code placement (was: Re: repo layout again)
Date Thu, 09 Mar 2006 13:50:06 GMT
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:
      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:
             means file is applicable for whatever system running Solaris;

            file is applicable only for  Windows / IA32;

            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


View raw message