Jose Alberto Fernandez wrote: > First I do not think I have all the answers, just to keep things in > perspective. What I think I have is a set of principles that I think any > viable solution should provide. Lets see if I can put them into words: ;-| > > 1) I should be able to determine the correctness (loosely used here) of a > buildfile by looking at that buildfile (and its dependencies) in > isolation. This means that the fact that I am imported by someone else > should not affect my correctness (modulo overriden targets). > > Rewriting of targets, may attempt at this correctness. > > How can we get something more interesting out of that principle above, I > agree is quite generic. Lets see...
Does it mean the imported buildfile needs to behave in the same way if it is used standalone or imported ? ( which implies all resolutions should be based on the imported file, etc ) ? > 2) It would seem we need to be able to specify whether a target can be > overriden or not. We need to be able to define if a target is: private, > final, or overidable. Notice that this is a property of the target and not > of the way the target is imported. Can you explain a bit more why a build file needs private or final ? I think if the syntax/semantic for the build file gets more complicated than the syntax for java, we are in trouble :-) > The meanings are: > private ==> other targets with same name on other files will not > override; > any mention on dependencies on this file for that target will > use this private version; > the target is not visible from outside the file. > > final ==> target visible from other files but not overidable, it is an > error; > any mention on dependencies on any file (without a private def) > uses this version. > > overridable ==> target visible from other files, and overridable; > any mention on dependencies on any file will use top > level available version. > > this are just suggestions, other levels of protection may be possible. I hope not. This sounds far too complicated, close to a "flexibility syndrome". One think I don't understand is why the import should be used as a OO substitute. Most languages I know define the import in a much simpler way. Maybe I'm missing too much of the context, I'm still trying to get updated with the mailing lists. Costin > On a project-fragment, any target dependency not defined in the fragment > will be picked up from the visible targets, following the rules above. > > I would suggest an attribute like: > > visibility="final|private|overridable" > > you may decide what should be the default. > > 3) targets can be overriden using <target/> which replaces the target > completely. Or using <override-target> which allows expressing > dependencies on the overriden target. The syntax in the dependency list is > to mention the name of the target itself n the list. > > <override-target name="compile" depends="precompile, compile, > postcompile"/> > > The "compile" target in the dependency list refers to the overriden > target. Notice that <override-target> requires target name to already > exist and be overridable. > > 4) To support multiple inheritance, I would allow defining a name for an > import. This name is only visible locally and can be used to specify in a > dependency list a target comming from an specific import. You can refer > that way to any target visible from that <import> but you cannot refer to > inner <imports> of those that have been overriden. You cannot use the > notation to break the visibility rules. > > <import file="xyz" name="a"/> > <import file="qrs" name="b"/> > > <target name="compile" depends="a->precompile, b->precompile"> > .... > </target> > > If xyz uses some other import that it names q, I canot say > a->q->precompile, because that violates the visibility rules defined in > xyz that provided its own target a->precompile. > > Ok, I will stop now, we can talk about implementation later. > > Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
