ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@m64.com>
Subject RE: [RFE] Richer Task Specification
Date Mon, 19 Jun 2000 13:11:22 GMT
> Other benefit of this approach is possibility to have more than
> one implementation
> of the taskdef and provide ability to switch between them at the runtime
> (i.e. standard idltojava and ORB proprietary compilers, another
> possible implementation -
> modern, jikes and standard compiler).
>

I think this is a really good idea although I haven't looked at the
mechanics you proposed. I had in mind a concept of a task-interface for
which multiple task implementations could be made available. <javac> would
be a task interface defining how all javac implementations would look. We
could then have various task implementations such as jikes, jdk, visualcafe,
etc. Continuing to graft these into the current Javac task via

if (compiler.equalsIgnoreCase("classic")) {
    doClassicCompile();
} else if (compiler.equalsIgnoreCase("modern")) {
    doModernCompile();
} else if (compiler.equalsIgnoreCase("jikes")) {
    doJikesCompile();
} else {
    String msg = "Don't know how to use compiler " + compiler;
    throw new BuildException(msg);
}

is not very elegant (nor very OO). We would need to provide a mechanism to
say what class provides the actual implementation of the interface. I'll go
back and look at your proposal to see how it could do that. In the case of
javac this would replace the use of ${build.compiler} which would probably
be a good thing.

I think this also addresses one of the issues raised in Pete's original mail
that started this thread ...

> Request 4:
> ----------
>
> A standardised set of taskdefs for invoking standard C/C++ tools (ie tasks
> like make, cpp, cc, link etc). I keep writing hacky ones for whatever
> particular compiler I am using at the time that are basically execs. Most
> of my compilations have relatively standard parameters so maybe
> it would be
> an idea to amalgamate them all into one task that then delegates to
> appropriate lower-level driver ????
>

A standard way of passing implementation specific extensions into these task
would also be a good idea, considering the idl compiler discussions.

Should we investigate the concept of task-interfaces further and the
required supporting mechanisms?

Conor



Mime
View raw message