At 01:22 PM 6/6/01 +0100, Jose Alberto Fernandez wrote: >> From: Peter Donald [mailto:[EMAIL PROTECTED] >> >> At 09:59 AM 6/6/01 +0200, Stefan Bodewig wrote: >> >>>The problem I have with this approach is, that whenever I ask for >> >>>real world examples of large scale projects I don't get any >> >>>responses. Or if I get responses and manage to solve the problems >> >>>without templates (the static kind) they get declared bad examples >> >>>afterwards. >> >> BTW it wasn't me who coined the term "dynamic" templates. >> > >My problem is with applying the term to <projectref> not with the existance >of it.
well it was me who applied to that use case. >> (B). T1 does not have any dependencies. You create a dummy >> target in in P1 >> that depends on T1, T2 if necessary and T3. This would rely on serial >> processing of dependencies. >> > >(C) Use "if" attribute on the predefined target. Just covering all possible >solutions. *sigh* >What is this extra maintenance work? Aren't tasks suppose to work as >adverticed? If I publish develop a task and say it does nothing when no >input is given, then it should keep on doing that on future revisions, the >same why it is suppose to keep on doing whatever it is that is suppose to >do. pfft. and if you don't what then? >Before you get into what we can do or not, can you tell me what you mean by >nested Fs? Fs are tasks, so are you talking about some new nested task >concept or something? Fs are features not tasks. Commonly Fs could be tasks but in many cases could be a set of tasks. Some Fs depend on existence of other Fs. > >> >> The other solution offered is what I have been pushing. >> Remembering that >> the situations that mandate templates will generally also mandate the >> presence of configuration/build engineers. While ant in it's >> current form >> is suitable for small and simple projects, it doesn't scale >> well to these >> sorts of situations. >> >> Ideally when you have access to build engineer, you may >> aswell make use of >> them. In the ideal scenario the "build file" will be a set of >> properties >> that are processed by "rules"/"templates" to generate instance. I have >> shown you my GNUMake file that facilitates this and you would >> have to agree >> that it is simpler to work with. In case you forgot, here is >> snippet from >> input file again. > >This is what I call embeded job security ;-) >We can't make the build tools too easy to use, those programmer may start >writing their own build files. And you consider this a good thing? Projects that have configuration managers have them more than just maintain build files but to also maintain build process. Personally when a resource is available I want to use it, you seem >As I told you in the past, you are just trying to impose on ANT those >patterns developed for MAKE. For example: > > $(wildcard $(SRCDIR)/dbg/*.cpp ) > >when were you goint to come and ask for $function-call notation for ANT so >you can give input lists explicitly? Don't be silly. Nothing in that snippet couldn't be done (or isn't already done) with ant datatypes. >I was wondering how were you planning to pass all >the different filesets and such for your expanded templates/configuration. same way it is done already? >Well, OK I give you the benefit of the doubt, you were planning to implement >this functionality in your JavaScript/JPYTHON Configuration stage. ;-) unlikely. >Althogh you can achieve this with the <configure> task we have already >mentioned and maybe even with the <style> or <anakia> tasks that exists >today. you can also write webservers with assembly. >I still think this is just advocating for having dialects in ANT, >each project its own. No common IDE is possible because there is no common >language for buildfiles. gee - the problem with that is? >How do you debug a builfile in this macro language? how many times do I have to answer the same question. The answer is the same today as it was yesterday. >You do not even know what is this suppose to expand to until you execute. >Or learn XSLT as to understand the templates. gee - don't let facts get in the way of you. You go girl. 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 | *-----------------------------------------------------*
