ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Cook <>
Subject Re: New tasks.
Date Thu, 04 May 2000 01:34:38 GMT
On Thu, 4 May 2000, Mariusz Nowostawski wrote:

> > It seems to me that, if you just want a tag of the form, 
> > <idl2java compiler="compilerX" options="compilerXoptions"/>
> > then exec is exactly what you're looking for.
> well, I would rather say:
> <idl2java compiler="compilerX" options="compilerXoptions">
>  <include name="${foo.FullOfIDLs.dir}/*.idl">
> </idel2java>
> instead of repeating the task for each single idl source, thus exec is not
> what would do the job nicely. 
> However, you are right, what I really want is a modified exec, sort of
> 'execFor' taks, which is similar to the existing one, but takes
> include/exclude tags as well, and effectively performs the given command
> with options and with list of files as last argument (with the 
> options to do it sequentially or at once all files in single command
> call). What do you think? 

I think we are looking for different things in the task; our company is
pretty much comitted to visibroker 4, and in fact has gotten it's fingers
burnt with some other products, and so is unlikely to use them. If you
want generic capability, then I think the execFor task is what you're
looking for. Now we just gotta write it :-).

> This would solve idl compilation for me just fine ;o)  I would sacrify the
> beauty of having seperate arguments for each option in the task (for
> example for orbacus idl compiler) for having a generic mechanism here
> instead.
> ----
> Most idl compilers are binary executables but
> parser generators are usually written in Java (antlr, javacc,
> sablecc) and we can take advantage of it. Execing for each grammar file
> seperate JVM has obvious drawbacks, thus I see a point in specialized
> optional tasks for each of them. What do you think?

On the other hand, visibroker's tools, which we use, are all java
executables, not native, so I can launch a compiler within the current
process; one idea I'm toying with is launching it in a separate thread,
although that would require some locking mechanism so you don't end up
compiling the implementatins and clients before generating the
stubs/skeletons, which would cause obvious problems.

Some sort of threading/locking mechanism would be fairly cool, IMHO. Start
each task in a separate thread, but also allow locking on arbitrary
strings. Something like:

<task1 ... lock="lock_a"/>
<task2 ... lock="lock_a"/>

Then have the project maintain a vector of lock strings. When a tast
starts, it checks for a lock attribute. Then it checks to see if the
corresponding lock string exists in the vector. If not, it creates it. If
it is, then it gets a reference to it. The rest of the function is then
synchronized on this lock object.

Opinions anyone? Is there any value of doing this apart from saying,
'Cool! We have a multi-threaded build tool!'?

Tom Cook - Software Engineer

"Never criticize a man until you've walked a mile in his shoes; that way,
when you criticize him, you're a mile away and have his shoes."
	- A froggy bloke on a news group.

LISAcorp -

38 Greenhill Rd.          Level 3, 228 Pitt Street
Wayville, SA, 5034        Sydney, NSW, 2000

Phone:   +61 8 8272 1555  Phone:   +61 2 9283 0877
Fax:     +61 8 8271 1199  Fax:     +61 2 9283 0866

View raw message