help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: .ALIAS builtin pseudotarget


From: Noel Yap
Subject: Re: RFC: .ALIAS builtin pseudotarget
Date: Thu, 23 Sep 2004 12:32:03 -0400
User-agent: Mozilla Thunderbird 0.5 (Windows/20040212)

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 <address@hidden> 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
address@hidden
http://lists.gnu.org/mailman/listinfo/help-make





reply via email to

[Prev in Thread] Current Thread [Next in Thread]