> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> Thus I come back to my question about why basedir override
> was implemented in the first place. I didn't get an answer I
> liked so far. Maybe it's because I always design my
> build/subbuilds in such a way that any basedir override
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> I am not happy with the way the current combination of ant/subant works.
> I can work around it, but only if I control how the upper level build
> file is invoking my build files, which is hard to do. And to justify.
> And to use at all if InheritA
Dominique Devienne wrote:
-Original Message-
From: Steve Loughran [mailto:[EMAIL PROTECTED]
In that case I have been using wrongly, forever.
Yep! Here's the corresponding manual section:
point taken. but it used to work :)
I always use the "dir" setting as it 100% guarantees that the di
> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>
> Peter Reilly wrote:
> > This is easy to explain and it is is the manal ;-)
> >
> > Using the will set the basedir as a user-like property,
> > which means that
> > it cannot be overwitten subsequently - i.e. it get
Peter Reilly wrote:
This is easy to explain and it is is the manal ;-)
Using the will set the basedir as a user-like property,
which means that
it cannot be overwitten subsequently - i.e. it gets "frozen".
You need to use : which
will set basedir property
as a non-user-like property.
In that
Steve Loughran wrote:
I am switching to my macro as we speak. I also note that
and definitions are fixed once declared, so you have to use
new names if you do things with different meanings. This makes sense,
but it did just catch me out. It does mean that "use unique
macro/preset def names f
This is easy to explain and it is is the manal ;-)
Using the will set the basedir as a user-like property,
which means that
it cannot be overwitten subsequently - i.e. it gets "frozen".
You need to use : which
will set basedir property
as a non-user-like property.
Peter
Steve Loughran wrote:
Steve Loughran wrote:
I have a problem w/ ant and subant that does not involve basedir being
set ; in smartfrog.org CVS for people who are curious, but I havent
checked this stuff fully in yet because it doesnt work.
Directory core/ at the base of things
And if I declare a macro aro
I have a problem w/ ant and subant that does not involve basedir being
set ; in smartfrog.org CVS for people who are curious, but I havent
checked this stuff fully in yet because it doesnt work.
Directory core/ at the base of things
Directory core/components/
ssage-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 14, 2004 7:08 AM
To: 'Ant Developers List'
Subject: RE: basedir not set corretly in subant task...
> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Dominique Devienne w
> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Dominique Devienne wrote:
> >>From: Alan Brown [mailto:[EMAIL PROTECTED]
> >>
> >>I have a master build file in Project that uses the Ant task to call
> >>targets in slave build files in the directories below it (tools,
Dominique Devienne wrote:
-Original Message-
From: Alan Brown [mailto:[EMAIL PROTECTED]
I have a master build file in Project that uses the Ant task to call
targets in slave build files in the directories below it (tools, server
and client). One of these slave build files (Tools) uses Suba
> -Original Message-
> From: Alan Brown [mailto:[EMAIL PROTECTED]
>
> I have a master build file in Project that uses the Ant task to call
> targets in slave build files in the directories below it (tools, server
> and client). One of these slave build files (Tools) uses Subant to call
>
The documentation for Subant clearly states...
* if you want to run directory1/mybuild.xml,
directory2/mybuild.xml, , use the antfile attribute. The subant task
does not set the base directory for you in this case, because you can
specify it in each build file.
However, this does n
14 matches
Mail list logo
