On 3/9/06, Oliver Deakin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
