IIRC, I have run into situations in which such a feature would've helped, but since I was able to find a different solution, I can't claim that this feature is absolutely necessary.
Considering that the alias can't really be referred to in the action part of the rule, I think .ALIAS is a bit misleading although I can't think of a different name at this moment.
Fabio Alemagna wrote:
On Thu, 23 Sep 2004 11:00:33 -0500, Boris Kolpackov <[EMAIL PROTECTED]> wrote:
As I said before, IMO, .ALIAS is useless because (1) when you need
timestamp you also need real target name and (2) when you don't need
real target name you don't need timestamp. The second case is covered
by .PHONY and the first - by normal targets. Therefore I don't quite
see where .ALIAS is useful.
Well, obviously if I do use it, and it serves its purpose, it IS useful.
The point is that I want a virtual file, a file which does't really exists but which still acts as a file. Perhaps you don't find it useful for your own needs, but I do, and some others might as well. Considering the patch is really tiny, I don't see the problem.
[short explanation of how does the build system work]
Don't see how this can be useful...
Well, what exactly you don't find useful? The build system as a whole, or just the shorthand thing? If you refer to the build system, I'd be interested in a more articulated opinion; if you referred to the shorthands, they come handy when you want to build only one module and you know there are no other modules with the same filename, to let you save typing, or when you want to build all modules in one directory, for whatever reason, without carying about the others. It's all about being able to selectively chose what to build and what not. If you don't need those features, you're free to not use them, but if you do need them, they're there.
I do need them, hence they're there. I'm not even sure this is the right place to discuss such a thing anyway. You asked me to point to things which the current make cannot do, and that's all I've done.
Let's try to stage a small project by the rules you gave above.
No need to do that, the build system has been working for more than
one year already, there's a whole project composed of lots of modules
which uses it, you might look at it as reference (notice that the
Makefile needs to be reworked and refactored, but the concept and the
Makefile.tubs files are completely valid):
http://cvs.sunsite.dk/viewcvs.cgi/aweb/
Say we have module `foo/foo' (executable) and `foo1/libfoo.so', `foo2/libfoo.so' and `bar/libbar.so'. So here we go:
[...]
foo/foo/DEPS := libfoo.so \ # short module name of type 2 bar/libbar.so # full module name
$(distdir)/foo/foo: $(foo/foo/DEPS) # ??? g++ -o $@ $^
---------------------------------------------------------------
The last rules won't work because when we link we need real libraries, their aliases are not good enough anymore.
But the last rule is wrong anyway. DEPS is not meant to contain object files suggest above, neither library names to be linked in the program. Those are _module_ names, in no way intented to be used the way you did. Look at the link I've given above to see how it works.
Fabio Alemagna
_______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-make
_______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-make
