nantcall task (was: Optional task: Visual Basic.NET compile)

["Felder, Brian" <BF...@providence.org>]

I like the approach of calling NAnt from Ant. Just out of curiosity, I built
a <nantcall> task. I'm attaching a first cut at this, with tests. It's
extremely simple: it takes a NAnt buildfile name, and a space-separated list
of targets. [NANT_HOME]/bin must be in the PATH for this to work.

I'm not sure if there are issues related to using this within Cruise
Control. If it works as Curt says, perhaps this would be a good way to have
Ant drive a build process that includes both Java and .NET code.

Brian

-----Original Message-----
From: Curt Arnold [mailto:carnold@houston.rr.com]
Sent: Saturday, September 07, 2002 10:38 PM
To: Ant Developers List
Subject: Re: Optional task: Visual Basic.NET compile


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>
stuff
> of <cc> for .net defines and references -there is no point reinventing
that
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
 
****************************************************************************
This message is intended for the sole use of the individual and entity to
whom it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.  If you are
not the intended addressee, nor authorized to receive for the intended
addressee, you are hereby notified that you may not use, copy, disclose or
distribute to anyone the message or any information contained in the
message.  If you have received this message in error, please immediately
advise the sender by reply email and delete the message.  Thank you very
much.                                                                       
  

Re: nantcall task (was: Optional task: Visual Basic.NET compile)

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Felder, Brian" <BF...@providence.org>
To: "'Ant Developers List'" <an...@jakarta.apache.org>
Sent: Monday, September 09, 2002 3:41 PM
Subject: nantcall task (was: Optional task: Visual Basic.NET compile)


> I like the approach of calling NAnt from Ant. Just out of curiosity, I
built
> a <nantcall> task. I'm attaching a first cut at this, with tests. It's
> extremely simple: it takes a NAnt buildfile name, and a space-separated
list
> of targets. [NANT_HOME]/bin must be in the PATH for this to work.

comma separated, surely. Spaces are valid in target names.
>
> I'm not sure if there are issues related to using this within Cruise
> Control. If it works as Curt says, perhaps this would be a good way to
have
> Ant drive a build process that includes both Java and .NET code.
>
> Brian

one thing that <ant> does is pass down  references and properties, messages
sent from below are passed up, things we have to replicate across processes.
We have the same problem with <nantcall> as one would have with <subant>
with fork=true, if that were ever implemented.

The obvious solution here is (and its a good one)
-define an XML wire protocol that can be used between an ant process and a
sub process.
-use that wire protocol over std-in and std-out, or over tcp loopback

If done right, the same protocol would work for nant, ant w/ forking and
remote access a la rant. SOAP would seem the obvious choice, though it
doesnt have a stdio transport that I am aware of.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>