Roger Vaughn <[EMAIL PROTECTED]> wrote:
> IMHO, the second option is inferior, though, simply because it looks
> kind of like a hack.
Sure, and it is a hack. I've been toying with an implementation of
the condition task for Ant 1 already - but there are so many things
waiting to get committed th
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hmm,
>
>
>
>
>
>
>
>
> would do it, no?
>
> Or with less features that are not there yet
>
>
>
>
> I think your case can properly be handled by target if/unless and
> setting some properties.
>
> Stefan
Hmm, yes, either would do i
Roger Vaughn <[EMAIL PROTECTED]> wrote:
> I have a set of targets for each OS that look like this:
>
>
>
>
>
>dir="${build.dll}"
> executable="make"
> os="Windows 2000"/>
>
>
> Notice that I use make to actually do the C++ compiles - t
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> We will have to deal with this problem in the context of
> multi-threaded execution of tasks in a target anyway. This probably
> means that bigger parts of the core need to be redesigned for
> multi-threading and that we document side-effects of some
Peter Donald <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Jun 2001 19:30, Stefan Bodewig wrote:
>> We will have to deal with this problem in the context of
>> multi-threaded execution of tasks in a target anyway. This
>> probably means that bigger parts of the core need to be redesigned
>> for multi-
On Mon, 18 Jun 2001 19:30, Stefan Bodewig wrote:
> >> At some point during discussion about Ant2 we've more or less
> >> agreed that there'll be an antcall version that doesn't use an
> >> execution context of its own - so that would cover (a) as well.
> >
> > Did we agreed to that? I thought we we
Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
> Let me first say that I am open here. I am just trying to get a
> discussion going and trying to teased people into thinking whether
> we need this at all and if we do how it should look like.
Sure, seems as if it didn't work though 8-(
>> At s
Stefan,
thanks for your comments. Let me first say that I am open here. I am just
trying to get a discussion going and trying to teased people into thinking
whether we need this at all and if we do how it should look like.
So here are some comments...
> From: Stefan Bodewig [mailto:[EMAIL PROTEC
Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
> So the aim is to: given a set of values apply XYZ to them.
>
> Question 1) What should XYZ be?
>
> There has been various proposals on this:
>
> a) a which is what the contributed task does.
>
> b) a group of s, with a construct that allows
From: Peter Vogel [mailto:[EMAIL PROTECTED]
> I guess my point is that "bad practices" will happen, no matter what
> you do to prevent them.
> > You've said more than once, that the common "recursive makefile"
> > pattern found almost everywhere in the make world was bad, even when
> > applied
The subject of performing iteration or applying a task to a certain group of
targets has appear regularly over and over again. I for one, think it is a
justified requirement but it needs to be designed carefully.
Now, careful design is not because we want to protect users against
themselves, but b
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
>
> >> Peter Vogel <[EMAIL PROTECTED]> wrote:
> >> > Except that "parallel" in the sense of execOn simply says that
> >> > it's ok to provide the whole fileset to the command at once,
> >> > rathe
Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
>> Peter Vogel <[EMAIL PROTECTED]> wrote:
>> > Except that "parallel" in the sense of execOn simply says that
>> > it's ok to provide the whole fileset to the command at once,
>> > rather than running the command for each file.
>
> I think one of
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> Peter Vogel <[EMAIL PROTECTED]> wrote:
>
> > Except that "parallel" in the sense of execOn simply says that it's
> > ok to provide the whole fileset to the command at once, rather than
> > running the command for each file.
>
> Or "apply the comm
Peter Vogel <[EMAIL PROTECTED]> wrote:
> Except that "parallel" in the sense of execOn simply says that it's
> ok to provide the whole fileset to the command at once, rather than
> running the command for each file.
Or "apply the command to the whole set instead of each member in some
arbitrary i
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> I think execon is there to stay and if it just was because of the
> parallel attribute.
>
> Whether execon and foreach could and should be based on the same code
> (I'm not talking copy-paste here 8-) is a completely different issue.
Fair enough - I
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Roger Vaughn <[EMAIL PROTECTED]> wrote:
>
> > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> >> is a different beast. As long as you say
> >> parallel="false", we are talking about iteration, but this nice
> >> little parallel attribute makes a
ge-
> From: Roger Vaughn [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 12, 2001 6:50 AM
> To: [EMAIL PROTECTED]
> Subject: Re: executing task for each file in file set
>
>
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > is a different beast. As long as
Roger Vaughn <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> is not a single file version, it is a no-file version which
>> happens to work on files in certain circumstances:
>
> Still, that doesn't invalidate my point, and in fact, I believe it
> reinforces it. S
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> I'm not sure we have this distinction yet. If it's in the
> distribution, it is in the core.
Sorry, I was making the distinction of invasiveness - is it a purely pluggable
task or does it affect the non-task source?
> > Exec, however, does *not*.
What about simple sets of sets of files? For instance:
I realize that on a case-by-case basis, we can solve
any and all needs for iteration, by masking them off
into custom tasks. However, this doesn't provide a
very mai
Roger Vaughn <[EMAIL PROTECTED]> wrote:
> Someone on the list has already written a foreach task - it's not
> part of the *core*, but including it in the distro would be helpful.
I'm not sure we have this distinction yet. If it's in the
distribution, it is in the core.
>> > Are we now going to
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> In certain circumstances - and I don't pretend that we can anticipate
> everything. To me foreach (or iterate or whatever) are probably most
> useful for sets that are not sets of files, but some new user defined
> data types.
That's an excellent po
Roger Vaughn <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> is a different beast. As long as you say
>> parallel="false", we are talking about iteration, but this nice
>> little parallel attribute makes all the difference
>
> Ah, a compelling argument.
Thanks - I
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> is a different beast. As long as you say parallel="false",
> we are talking about iteration, but this nice little parallel
> attribute makes all the difference - you can transform a whole set of
> files at once, without any iteration. is a little
Peter Vogel <[EMAIL PROTECTED]> wrote:
> I guess my point is that "bad practices" will happen, no matter what
> you do to prevent them.
Agreed.
> I challenge you to describe what a number of core and/or official
> optional tasks do without using the words for, each and if.
writes a message to
--- [EMAIL PROTECTED] wrote:
> Having now read the requirements doc for ant2, I think that keeping foreach
> out of the core, but anticipating that those who want it will grab it, is the
> best way to present the 'right' way without being draconian. I, for one,
> would drop out of the debate were
=> On Mon, 11 Jun 2001 17:56:31 -0700 (PDT), Roger Vaughn <[EMAIL PROTECTED]>
said:
>>> Say we'd add foreach to the core - and I'm more and more leaning towards
>>> it (making myself a heretic, I guess 8-) - and we already have those many
>>> cases where we successfully anticipated the need for
--- Peter Vogel <[EMAIL PROTECTED]> wrote:
> I guess my point is that "bad practices" will happen, no matter what
> you do to prevent them. In Ant's case, it's way to possible to commit
> a multitude of sins in a series of optional tasks that unnecessarily bloat
> the
> "vocabulary" of build des
>
> > Personally, I'd like to see the ant designers stop "babysitting" the
> > development community to prevent what they view as "bad practices".
>
> In my case, it's less about babysitting the users than preventing that
> "bad practices" applied by users will be used as an argument against
> An
Peter Vogel <[EMAIL PROTECTED]> wrote:
> Personally, I'd like to see the ant designers stop "babysitting" the
> development community to prevent what they view as "bad practices".
In my case, it's less about babysitting the users than preventing that
"bad practices" applied by users will be used
uations.
-Peter
> -Original Message-
> From: Daniel Barclay [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 23, 2001 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: executing task for each file in file set
>
>
> Peter Donald wrote:
> >
> > At 04:25 PM
At 10:18 AM 5/23/01 -0400, Daniel Barclay wrote:
>For ideas that have been rejected, are they permanently rejected?
probably not - the majority of ideas were rejected in context of ant1 and
we never really discussed possibilities (except when discussin frANTic
proposal) a while back.
>Do the Ant
Peter Donald wrote:
>
> At 04:25 PM 5/22/01 -0400, Daniel Barclay wrote:
> >I was asking more about how solid a set of standard features Ant tries
> >to provide.
> >
> >(Obviously, Ant provides a lot, but with its inconsistencies and
> >limitations and the frequent suggestions to just write custom
> From: Peter Donald [mailto:[EMAIL PROTECTED]
>
> >Or is there any expection of writing build files that use
> only standard
> >features so those build files can run on any base (uncustomized) Ant
> >installation? (I don't necessarily mean eschewing (wow, I
> don't usually
> >think of that word)
Daniel Barclay <[EMAIL PROTECTED]> wrote:
> Actually, I wasn't asking in relation to task libraries.
Well, you asked in the context of a foreach task (where I said it
wouldn't make it into core but be written). To me this is asking for
task libraries as I suspect foreach is going to be available
At 10:35 AM 5/22/01 -0400, Daniel Barclay wrote:
>Stefan Bodewig wrote:
>>
>...
>> Ant2 will give task developers the infrastructure to write a foreach
>> task (like J.D.'s) by allowing tasks to be nested into other tasks.
>>
>> While I doubt that a or task will make it into
>> Ant's core, they
At 04:25 PM 5/22/01 -0400, Daniel Barclay wrote:
>I was asking more about how solid a set of standard features Ant tries
>to provide.
>
>(Obviously, Ant provides a lot, but with its inconsistencies and
>limitations and the frequent suggestions to just write custom tasks for
>(arguably) generally
Stefan Bodewig wrote:
>
> Daniel Barclay <[EMAIL PROTECTED]> wrote:
>
> > Is the usual expectation that a system using Ant build files would
> > contain a copy of Ant bundled with all the particular add-ons used
> > by those build files?
> >
> > Or is there any expection of writing build files th
Daniel Barclay <[EMAIL PROTECTED]> wrote:
> Is the usual expectation that a system using Ant build files would
> contain a copy of Ant bundled with all the particular add-ons used
> by those build files?
>
> Or is there any expection of writing build files that use only
> standard features so tho
Stefan Bodewig wrote:
>
...
> Ant2 will give task developers the infrastructure to write a foreach
> task (like J.D.'s) by allowing tasks to be nested into other tasks.
>
> While I doubt that a or task will make it into
> Ant's core, they are certainly going to be written.
What is Ant's (or, r
Daniel Barclay <[EMAIL PROTECTED]> wrote:
> Does the for-each processing proposed for Ant2 cover running some
> task or series of tasks over each file in a file set?
There is no proposed foreach processing for Ant2, sorry.
Ant2 will give task developers the infrastructure to write a foreach
task
nt-dev
> Subject: executing task for each file in file set
>
>
> Does the for-each processing proposed for Ant2 cover running some task
> or series of tasks over each file in a file set?
>
> I'd like to something like:
>
>
>
> for each file in a fileset lik
21, 2001 3:11 PM
To: ant-dev
Subject: executing task for each file in file set
Does the for-each processing proposed for Ant2 cover running some task
or series of tasks over each file in a file set?
I'd like to something like:
for each file in a fileset like:
Thanks,
Daniel
--
Dan
Does the for-each processing proposed for Ant2 cover running some task
or series of tasks over each file in a file set?
I'd like to something like:
for each file in a fileset like:
Thanks,
Daniel
--
Daniel Barclay
Digital Focus
[EMAIL PROTECTED]
45 matches
Mail list logo
