ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: [Q] How to avoid <antcall> with generic <script> target for s ubprojects?
Date Fri, 28 Mar 2003 19:42:19 GMT
No problem. And you always can modify SubAnt.java locally to fit your own
needs.
That's what great about OSS, isn't it ;-) --DD

PS: I'm curious about this approach of not having projects checked out... I
also
    lurk on the TortoiseCVS list, and people there also talk about it. I
personnally
    have litterally dozens of CVS sandboxes on my machine, both from my own
company
    and from many OSS projects. I would myself just have it all on my disk,
and update
    only part of the sandbox I want, plus the common.xml file.

PPS: Interesting post. Thanks ;-)

-----Original Message-----
From: Andreas Ames [mailto:andreas.ames@tenovis.com]
Sent: Friday, March 28, 2003 11:06 AM
To: user@ant.apache.org
Subject: Re: [Q] How to avoid <antcall> with generic <script> target for
s ubprojects?


Dominique Devienne <DDevienne@lgc.com> writes:

> That's an interesting use case you are discribing. I never thought of it
> myself, in part because I would have use another approach... Instead of
> reusing the *same* build file for all the projects, which forces you to
> explicitly set the basedir (using the 'dir' attribute), something I'm not
> fond of, I would have created a hollow buid file for each sub-project that
> (XML entity) includes a common.xml build file. That way, I can still build
> each project individually (usually assuming it's dependencies have been
> built before), and have them *share* a common build file content. Most
> likely, your superproject build file contains stuff of no use to itself,
> just for the benefit of the subprojects.
> 
> Given the approach described above, <subant> works like a charm. This is
> actually how I've recently set things up to compile 30 shared libraries...
> This approach also gives you a bit more flexibility, in that you can
> slightly customize the build file for a given subproject. In my particular
> use case, one shared lib requires code generation (.y/.l files), and I do
> this in that project's build file only. You could argue that I could have
> dealt with this in common.xml too, but it's actually simpler that way.

Thanks for your explanation.  I've just two or three remarks about why
I want to keep one build.xml as long as it is possible:

- My build.xml resides at a given position in our cvs tree.  Sometimes
  (rather often) developers (including me) don't want to checkout the
  whole cvs module if they just have to do something in a library
  subproject.  They just checkout the according subtree.  With a
  single antfile they just have to checkout this file additionally
  (possibly even via web/viewcvs) put it whereever they want abd use
  it.  The default place is the toplevel 'build' subdir and calling
  'ant' will do the job (otherwise they have to specify the initial
  basedir at comandline which is also no problem).  With the
  'common.xml' include-approach the subproject's build.xml expects
  this file at a fixed position relative to the subtree.  This will
  more or less force them to checkout the whole module or always edit
  the build.xml, something I don't want to require.

- I'm using psgml to edit the antfile.  A common.xml can't have a
  DOCTYPE (afaik) and I have always to specify the DTD after loading
  the common.xml (no big deal but I'm lazy ...)

You might be right that keeping everything in one build.xml will be
the more painfull the more complex the buildprocess gets, when this is
the case I will certainly resort to your modularized approach or
something similar.

As the patch that I'm proposing won't break any existing code, AFAICT,
I will just send it to the BTS against SubAnt.java's head revision in
ant's cvs repository.  We will see what happens.


Thanks

andreas

Mime
View raw message