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 Mon, 20 Feb 2006 21:35:46 GMT
On 2/17/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> do you have any examples (i.e. snippets of a non-trivial Ant script)
> that show what it would end up like?  I'm trying to figure out in my own
> head whether it would be a few general regex selectors, or a load of
> them!  I think you may be do it with just a few, right?

Actually not as few as I would wish. The selectors themselves are 4
lines, plus ~15 lines of logic ops to combine them. However, the rest
of code which does necessary conversions is big. Finally, the code
snippet that worked for me is like this:

    <!-- Translate fileset into plain string first -->
    <pathconvert property="source.files" pathsep=",">
        <path>
            <fileset dir="${basedir}" includes="**/*.c"/>
        </path>
        <map from="${basedir}" to=""/>
    </pathconvert>

    <!-- Filter plain string using regex -->
    <for list="${source.files}" param="file">
        <sequential>
            <propertyregex property="OS.match" input="@{file}"
regexp="[\W_]${env.OS}[\W_]" override="yes" defaultValue="no"
select="yes"/>
            <propertyregex property="OS.any.match" input="@{file}"
regexp="[\W_](win|linux|solaris)[\W_]" override="yes"
defaultValue="no" select="yes"/>
            <propertyregex property="ARCH.match" input="@{file}"
regexp="[\W_]${env.ARCH}[\W_]" override="yes"  defaultValue="no"
select="yes"/>
            <propertyregex property="ARCH.any.match" input="@{file}"
regexp="[\W_](ia32|sparc|ipf)[\W_]" override="yes"  defaultValue="no"
select="yes"/>
            <if>
                <and>
                    <or>
                        <istrue value="${OS.match}"/>
                        <not>
                            <istrue value="${OS.any.match}"/>
                        </not>
                    </or>
                    <or>
                        <istrue value="${ARCH.match}"/>
                        <not>
                            <istrue value="${ARCH.any.match}"/>
                        </not>
                    </or>
                </and>
             <then>
               <var name="filetered.files" value="${filetered.files},@{file}"/>
             </then>
            </if>
        </sequential>
    </for>

    <!-- Convert string back to fileset -->
    <path id="filetered.files.path">
        <filelist dir="." files="${filetered.files}"/>
    </path>
    <pathtofileset name="filetered.files.fileset"
                           pathrefid="filetered.files.path"
                           dir="${basedir}"/>

    <!-- Call C compile task with the resulting fileset -->
    <cc objdir="out">
          <fileset refid="filetered.files.fileset"/>
    </cc>
    </target>

It doesn't look too small because the original ant fileset regexp
selectors don't work with the directory names, hence one has to apply
some magic (convert fileset to string, filter it using regexp, and
then convert back to files). I imagine that the above code should look
much simpler if write a custom regexp selector class.

The reason why it doesn't look too simple is that we allow an
arbitrary delimiter like [\W_] for OS/ARCH attributes, and we catch
partially shared file names like "linux_solaris".

I didn't try yet to implement the same logic with make, would it be
much simpler?

Thanks,
Andrey.

>
> Regards,
> Tim
>
> >> Using the names consistently will definitely help, but choosing whether
> >> to create a separate copy of the file in a platform-specific
> >> sub-directory, or to use #define's within a file in a shared-family
> >> sub-directory will likely come down to a case by case decision.  For
> >> example, 32-bit vs. 64-bit code may be conveniently #ifdef'ed in some .c
> >> files, but a .h file that defines pointer types etc. may need different
> >> versions of the entire file to keep things readable.
> >
> > Yes, I agree. This is why I suggest to keep both selection mechanisms
> > - sometimes #define is more efficient, and sometimes dir/filename is
> > much more clear.
> >
> >>> 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?
> >
> > Let's consider both for now :)
> >
> >> 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.
> >
> > Agreed. I think it would be great if  we can keep our inter-component
> > interfaces (like vmi.h) platform independent.
> >
> >
> > Thank you,
> > Andrey Chernyshev
> > Intel Middleware Products Division
> >
> >
> >>> 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?
> >> 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
> >>>>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>

Mime
View raw message