Peter Donald <[EMAIL PROTECTED]> wrote: > At 11:00 13/12/00 +0100, Stefan Bodewig wrote: >>Peter Donald <[EMAIL PROTECTED]> wrote: >> >>> While I won't block such a move I think it is possibly an example >>> of flexability syndrome mentioned a few days ago. Can you think of >>> any *good* use case for changing the value of either name or >>> default attributes of project or name attribute of target? >> >>Not really. I do see valid use cases for setting project's basedir >>based on user.home for example. > > Could you expand on this and give an example of when it would be > useful. ie When would the current mechanisms fail and how would this > solve it. Also could it be solved by making basedir a special > property. ie place "-Dbasedir=foo/" on command line.
Actually what you suggest (setting basedir on the command line) works right now, this is what I recommend on ant-user as well. If you do so you must not specify a basedir attribute for project at all. The docs say all attributes of project would be required, but Ant doesn't really enforce this - quite the opposite. It boils down to convenience, user.home has already been set by the JVM, probably based on $HOME, so why should I have to specify it on the command line again. > >>> I see much much danger in evaluating depends attributes. >> >>If we were going to expand them at runtime that is, right. Actually >>I was proposing to expand them at parser time - should have been >>clearer. When it comes to <project>, parser time and runtime are the same. We need to know the basedir of a project when setting the dir attribute of a <fileset> for example. Evaluating the depends attribute at runtime would be a real pain as you could not calculate the dependency graph up front and might realize there is a cycle when you are half way through the build. If we evaluate them at parser time, the problem would go away, but that might make it less useful to those who want to expand properties in the depends attribute, not sure. >>> Besides the fact that has been asked for can you think of any good >>> reasons to include it? >> >>Consistency. > > good point. If we are going to make if/unless evaluated then it > definetly becomes an issue - however they are evaluated at interpret > time. Not sure thou. You are right. Expanding the if/unless attributes at parser time doesn't make much sense to those who ask for that feature. Almost looks as if the only consistent way was to keep the current behavior but change the documentation of project to better reflect the truth. Thank you for making me rethink the whole issue Stefan
