At 03:24 16/5/01 +1000, Conor MacNeill wrote: >> From: Peter Donald [mailto:[EMAIL PROTECTED] >> >> if you mean the ant-calls for src and bianry distributions then I agree - >> UGLY ;) Though it is better than any alternative I could think of - you ? > >True enough. I think we are using these antcalls primarily as a way to get >around the immutable properties in Ant - right? So, I see these resulting >from another Ant "feature". We solve that problem using the tools at hand - >antcall.
right. >I like this discussion since we should always be ready to question whether >there is a better way of doing things. That is why I'd like to hear from Jon >on his thoughts for a better way of doing the uptodate checks. uptodate is a >direct result of the if/unless mechanisms we currently have. Is there a >better way? I don't know about Jon but I don't like the general premise of the "uptodate" task. Namely that checking if something is upto date is done independently of actually doing thing. In my opinion all "compile"-like tools regardless of language (idl/java/c/whatever) should automagically incorporate functionality of "uptodate" and "depends". I haven't mentioned this because I am not willing to do the work ;) >> >Is writing tasks the right way? I'm not sure that is true. >> >> Could you explain why? ie What do you see wrong with writing a task for >> complex build "tasks". > >I see tasks as appropriate when you tend to do the same type of things in >many places or in many builds. That is, I see them as a solution when you >can apply them in multiple places. I'm wary of using tasks for ad-hoc >conditional requirements in the build. Can you see a task or tasks for the >Ant build that handles all the conditionals we currently have. Look at the ><exclude> elements in the compilation. okay - never thought of that. I guess I still see build file as a set of operations given data. I have no problem with conditional data (ie files included in build, location of destination etc) but I thing I do have a problem with allowing conditional operations (ie only do X in condition Y where X is a task). >Moving that into its own task would >make the build much more difficult to understand. At one extreme it would >become ><buildant> > >:-) don't laff - my trips into xslt and ant had such toplevel targets as <stylebook/> <javac/> ;) >> If you are referring to the initial setting of properties and general >> autoconf-like features then I agree that writing a task is >> overkill as most >> tests will be project specific. (I believe autoconf should be written in >> some scripting language like jython/rhino or another BSF mounted scripting >> language). However for the other stuff I think task writing is >> the WAY to go. >> > >So, why don't we use that in the ant build file? WOuld it be better, more >easily maintained? I'm not convinced. Well one thing it would mean is that we require dynamic templating. As it stands now the process is configure -> template -> execute However if we place configure in same place as execute it almost certainly means we need template in same build file aswell. This of course means we need to turn ant into essentially a dynamic XML script (yuck). This makes things a lot harder for us in long run (we will end up supporting a feature set like make) but easier in short turn. >BTW, I'm not arguing for any particular view. I'm not sure what is the best >compromise, myself. Ever since someone "explained" to us how dynamic templating is evil (sorry can't remember who it was) my view has been basically something like 1. User starts ant build 2. Configure tool launches that checks a whole bunch of things, sets properties and saves properties into some store 3. template tool starts up and reads in configure properties (ie as XSLT params or equiv) and uses them to generate a "real" build file 4. ant runs "real" build file and preloads properties from configure Now that is fine for small->medium scale projects. All the transformation is done in memory and the configure properties are loaded in memory aswell. For large scale projects you may want to do each step separately (performance reasons) - not sure. I was thinking that with ant2 we could try to get (3) working and with ant3 get the whole shebang on the road - not sure ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
