ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurence Mills-Gahl <>
Subject Fwd: Re: Output of perl exec behaving oddly (solved)
Date Mon, 24 Jan 2011 17:24:03 GMT
Just in case anybody else runs across this...

Setting the inheritall="yes" on the foreach task did the trick. Setting
the build directory at the top of the target now persists through all of
the invocations in the foreach task.

-------- Original Message --------
Subject: 	Re: Output of perl exec behaving oddly
Date: 	Mon, 24 Jan 2011 10:41:19 -0500
From: 	Laurence Mills-Gahl <>

I wasn't looking at the ${BUILDTIME} property because I was assuming
that wouldn't change during the run, but it is (I noticed the output
directory created ended with 20110124103046 (the timestamp) and the
second invocation of compile_patients_on_alert was trying to write a
file to 20110124103052. So your initial comment on immutability of
properties was helpful because I was assuming  ${BUILDTIME} would not
change (and it did... yikes!)

Hmmmm... I'm going to have to look at the foreach task to see if it
creates an entirely new ant invocation with each iteration... that would
be the easy way to allow properties to change and it would explain why
the timestamp (that is only set in the top of the project) appears to
change when it shouldn't... hmmm. That would also explain the apparent
inconsistency in that if the execs were spawned quickly enough (when I
was trying spawn="yes" ) they might get into the same timestamped
directory, but then eventually, one wouldn't).

Hmmm... time to dig in to the foreach environment a bit.

Thanks for looking at this.


On 1/24/11 8:25 AM, Michael Ludwig wrote:
> Laurence Mills-Gahl schrieb am 24.01.2011 um 00:56 (-0500):
>> On 1/23/11 10:12 PM, Michael Ludwig wrote:
>>> Laurence Mills-Gahl schrieb am 23.01.2011 um 21:27 (-0500):
>>>> I have a list of centerid's and a "foreach" loop
>>> Red flag goes up …
>> What is the red flag?
> Ah, that was just a manner of speaking.
> I was on the wrong track, sorry. :-)[...]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message