> The idea is good, however I think including both the OS and arch in the > directory name is preferable. > It is just as simple a convention, gives the coder an at-a-glance view > of which OS/arch's have platform specific code associated with them > and keeps the actual source filenames consistent across platforms. > > Was there a particular reason for attaching the architecture to the > filename and not the directory Andrey?
I think there is no particular reason except just a convenience. People may not wish to create extra directory and go there each time because of a few platform-dependent files. Also, as I mentioned in my previous message, every extra source directory may additionally complicate the setup of debugging tools and IDE's. > I agree that is a perfect scenario to use VPATH for. I think this would > probably be a simpler solution > than using ant (as suggested later) and also would not require you to > have a JVM to build the native code. We have a lots of Java code in a source base, right?:) Therefore one will need a JVM anyways to be able to build something runnable. > This is a tricky one. I think in most cases the difference between > 32/64bit code should be minor and > mostly confined to header defines as Tim suggests. For this ifdef's will Let's don't forget about the different OS'es and architectures. For example, I'd expect significant difference in implementations for AWT on Win/X11 and JIT compiler on IA32/Sparc/IPF. The whole design of the code could be different, not just implementations of certain functions or classes. Using #defines only could be almost nightmare in this case... > be sufficient. I would simply suggest > that we adopt a policy of always marking all #else and #endif's clearly > to indicate which condition > they relate to. > However, there may be instances where using ifdef's obfuscates the code. > I think most of the time this > will be a judgement call on the part of the coder - if you look at a > piece of code and cannot tell what > the preprocessor is going to give you on a particular platform, you're > probably looking at a candidate > for code separation. I agree, this seems to be a good criteria for choosing between defines and dir/file names. Thank you, Andrey Chernyshev Intel Middleware Products Division > > > >> Finally, I'd suggest that the platform dependent code can be organized > >> in 3 different ways: > >> > >> (1) Explicitly, via defining the appropriate file list. For example, > >> Ant xml file may choose either one or another fileset, depending on > >> the current OS and ARCH property values. This approach is most > >> convenient, for example, whenever a third-party code is compiled or > >> the file names could not be changed for some reason. > >> > > > > Ant ?! ;-) or platform-specific makefile #includes? > > > > > >> (2) Via the file path naming convention. This is the preferred > >> approach and works well whenever distinctive files for different > >> platforms can be identified. > >> > > > > yep (modulo discussion of filenames vs. dir names to enable vpath) > > > > > >> (3) By means of the preprocessor directives. This could be convenient > >> if only few lines of code need to vary across the platforms. However, > >> preprocessor directives would make the code less readable, hence this > >> should be used with care. > >> > >> In terms of building process, it means that the code has to pass all 3 > >> stages of filtering before it is selected for the compilation. > >> > > > > I like it. Let's just discuss what tools do the selection -- but I > > agree with the approach. > > > > > >> The point is that components at Harmony could be very different, > >> especially if we take into account that they may belong both to Class > >> Libraries and VM world. > >> > > > > There will be files that it makes sense to share for sure (like vmi.h > > and jni.h etc.) but they should be stable-API types that can be > > refreshed across the boundary as required if necessary. > > > > > >> Hence, the most efficient (in terms of code > >> sharing and readability) code placement would require a maximum > >> flexibility, though preserving some well-defined rules. The scheme > >> based on file dir/name matching seems to be flexible enough. > >> > >> How does the above proposal sound? > >> > > > > > Sounds good :) It makes a lot of sense to organise the code in a way > that promotes reuse across platforms. > +1 from me > > > -- > Oliver Deakin > IBM United Kingdom Limited > > > > > Cool, perhaps we can discuss if it should be gmake + vpath or ant. > > > > Thanks for resurrecting this thread. > > > > Regards, > > Tim > > > > > > > >>>> Maybe in some components we would want to include a window manager > >>>> family too, though let's cross that bridge... > >>>> > >>>> I had a quick hunt round for a recognized standard or convention for OS > >>>> and CPU family names, but it seems there are enough subtle differences > >>>> around that we should just define them for ourselves. > >>>> > >>>> > >>> My VM's config script maintains CPU type, OS name, and word size as three > >>> independent values. These are combined in various ways in the source code > >>> and support scripts depending on the particular need. The distribution > >>> script > >>> names the 'tar' files for the binaries with all three as a part of the > >>> file name > >>> as, "...-CPU-OS-WORD.tar" as the tail end of the file name. (NB: I am > >>> going > >>> to simplify the distribution scripts shortly into a single script that > >>> creates the > >>> various pieces, binaries, source, and documentation. This will be out > >>> soon.) > >>> > >>> Does this help? > >>> > >>> Dan Lydick > >>> > >>> > >>>> Regards, > >>>> Tim > >>>> > >>>> > >>>> -- > >>>> > >>>> Tim Ellison ([EMAIL PROTECTED]) > >>>> IBM Java technology centre, UK. > >>>> > >>> > >>> Dan Lydick > >>> > >>> > > > > > >
