[Ant-contrib-developers] some thoughts on merging the tasks

[Adam M. <ada...@ya...>]

Hi,

A good place to start with the task unification is to decide what we want
the unified task to look like in the build files.

I'd like to suggest that we start with the interface from my proposal (of
course).  It's based, more or less, on the discussion that happened on
ant-dev and ant-user a few months ago, with additional stuff from
discussions between Mark and myself.  Have a read here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/ant-contrib/cpptas
ks/base-implementations/Murdoch/cc.html

A few things I'd like to change:

* Expose compiler and linker specific config, and allow custom compiler and
linker implementations to be used.

Perhaps we get rid of the "compiler" attribute, and replace it with nested
<compiler> and <linker> elements.

<compiler> would have the following attributes:

- name: The compiler adaptor to use, e.g "vc", "gcc", etc.
- classname: The classname of the compiler adaptor to use.  Not used if
"name" is specified.
- if, unless: same as everywhere else.

It would also allow adaptor specific config as well, e.g. precompiler header
stuff for msvc, or compiler specific optimisation or warning options.

It would allow nested <defineset> and <compilerarg> elements.

E.g.

<cc>
    <compiler name="vc" if="os.windows">
        <compilerarg value="/SOMEFLAG"/>
        <defineset define="SOME_VC_DEF"/>
    </compiler>
    <compiler name="gcc" unless="os.windows">
    </compiler>
</cc>

<linker> would work very similarly.  It would have the following attributes:

- name: The linker adaptor to use.
- classname: The classname of the linker adaptor to use.
- if, unless.

It would allow nested <libset> and <linkerarg> elements in here.

Probably a useful thing would be to include a compiler and linker adaptor
which can be used to define new compilers and linkers, without the user
having to write any code.

E.g.

<cc outfile="build/bin/someapp">
    <compiler
            name="custom"
            executable="newcc"
            includeflag="-I"
            defineflag="-D"
            undefineflag="-U">
        <compilerarg value="--someflag"/>
        <debugarg value="-g"/>
        <debugarg value="--someflag"/>
    </compiler>
    ...
</cc>

The <compiler> and <linker> elements would be optional, and a default
compiler and linker would be used if they weren't present.

It would probably be useful to turn <compiler> and <linker> into datatypes,
and allow them to be referenced by id (may need some changes to Ant's
introspection code to do this), so that they can be reused across <cc>
tasks.


* Conditional stuff.

We probably should add "if" and "unless" to <defineset> and <libset>.
Alternatively, we could use the <compiler> and <linker> elements as the
place for conditional defines and libs.  This would also solve the problem
for <compilerarg> and <linkerarg> (these are Commandline datatypes, and
don't have "if" and "unless" either).

The problem is, conditional stuff is often independent of the compiler being
used.  Which suggests another nested element type - <cconfig> or whatever -
that can be used to group together conditional stuff.  This might be getting
a bit carried away.  We can always add it later.


Adam