ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Curt Arnold" <>
Subject Re: Optional task: Visual Basic.NET compile
Date Sun, 08 Sep 2002 05:37:49 GMT
There are a whole lot of worms in this message.  I'm going to try to pull a
few out.

Erik Hatcher wrote:
>    Since there is already NAnt and NDoc, it seems a bit much for us in
> Java-land to reinvent the wheel.  If their projects are good enough for
> .NET development, doesn't it make sense for us to deprecate what we have
> in that area and refer to them?  Ant can call their build and they could
> call us when projects need to cross those boundaries.

If you are using CruiseControl, then the process would need to be driven
from an Ant build (to the best of my knowledge).  Nant seemed didn't seem to
have any version control tasks in their documentation.  Also, users may have
custom Ant tasks, they don't want to replicate for NAnt.

However, if there was <nantcall> task or a processor="ant | nant" attribute
on the existing <antcall> task, then Ant could hand off to Nant for .NET
specific stuff while still being able to use good stuff that is only
available in the Ant world.

> What I'd like to do would be to leverage the <defineset> and <libset>
> of <cc> for .net defines and references -there is no point reinventing
> stuff. But to do that, we'd have to pull the <cc> codebase in to ant's CVS
> tree. Do you think it is time? I do.

I've spent a few spare cycles on thinking how the .NET compile tasks could
be cast in terms of the cpptasks framework.   What troubled me was that csc
and the other compilers didn't fit the traditional role of a compiler in the
compile link cycle since they compile and link in a single step.  It is a
bit counter-intuitive, but I think csc fits the role of a linker and could
be dropped into the cpptasks framework.  There'd probably need to be a
CSCCompiler object, but its only action would be to bid 0 on everything
(like traditional compilers do on object files) so they pass to the link
step.  There would probably need to be a few other minor changes.

I believe  the non-cpptasks tasks are self-contained enough that you could
incorporate anything that is thought to be is generally useful.

For the cpptasks stuff, I would prefer that code convention. doc comment and
other tune-up work be done in the ant-contrib project, so that at the moment
of integration the ant-contrib and ant code bases only differ by package
names and copyright notices.

I was amused that there is a Nantcontrib project at SourceForge.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message