I like the idea of targetless build files, as long as it doesn't create a magic name, (other than perhaps "do_nothing_for_the_sake_of_Peter" which is amusing enough to allow :). If this is implemented, I think we should consider requiring that all non-target tasks occur before the first <target/>. I don't like the idea that there could be 40 lines of init stuff, at the top, and 10 targets, and 2 init lines at the bottom, that got added because I was lazy, but set a property that mucks things up later... and I can't figure out where it is being set.
So we would probably need to make exceptions for taskdef, property, and typedef because they are already allowed anywhere, but could perhaps deprecate that sort of usage, and put in a slightly annoying warning that would motivate people not to continue this usage, and fix their old files. Since the fix is a simple cut and paste type of thing it wouldn't be too painful, I think. Also, allowing setup stuff to be interspersed with targets would lead to a very counter intuitive reading of the build file. People don't naturally read like a parser... and we should be striving to keep things as human readable as possible. Forced organization = good. Not forced organization = difficult. I am not a commiter, but I am in favor of targetless builds... so +1ish :) Gus Conor MacNeill wrote: > > Stefan Bodewig wrote: > > > > +1 to target-less build files. > > > > +1 > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
