Anyone consider:
<target name="sometarget" depends="super.sometarget"> ...
Nicola Ken Barozzi wrote:
You could make the argument that the name isn't really an internal. It's just an alias to reference the project since using the filename might not be desirable. Java and some other languages base the name of a class or module on the file or require the two to be the same. But what about C++, and probably others. You can declare whatever classes you want in a .h file with any name and yet you still expect the user to include some "file name" (e.g. <sstream>) and then use classes defined inside that file which may hve difference names (e.g. stringbuf, ostringstream,...).Jose Alberto Fernandez wrote:
Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the import.
This in my opinion contradicts the hidding rules of OO programming. I should not need to know about the internals of an imported object. It also means that I have to coordinate all the files I may directly or indirectly import so that there is no project name clashes.
Some of the information defined inside the imported build file has to be accessible to the outside. It seems reasonable that, just like the target names, macro, presets, tasks, selectors, properties, .... the project name could be one more piece of useful information. You just now have to be careful not to rename the project if others might be importing your build file....just like any resource, in any imported/included file, is virtually any language.
Evan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
