harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Chernyshev <a.y.chernys...@gmail.com>
Subject Re: Platform dependent code placement (was: Re: repo layout again)
Date Fri, 17 Feb 2006 16:55:24 GMT
> 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 (t.p.ellison@gmail.com)
> >>>> IBM Java technology centre, UK.
> >>>>
> >>>
> >>> Dan Lydick
> >>>
> >>>
> >
> >
>
>

Mime
View raw message