Re: RFC: .ALIAS builtin pseudotarget

[Boris Kolpackov]

Please CC address@hidden if you want to discuss stuff like this.

Fabio Alemagna <address@hidden> writes (full quote):

> > Now to your proposal: what you are suggesting essentially is
> > a timestamp but the prerequisite is hidden, there is no way you can
> > access it. Here is an example:
> > 
> > .ALIAS: alias
> > 
> > alias: foo.c
> > 
> > foo.o: alias
> >         $(CC) -o $@ -c ???
> 
> I get what you mean, so the limited use of this special target perhaps
> doesn't warrant it the right to be added to Make.
> 
> For sake of completeness, though, I must say that I have come up with
> this approach only as a mid-term solution for something more general
> purpose I had thought I would implement. This .ALIAS target served my
> purposes, so I implemented it to see whether I could hack Make's
> sources.. however, the more general idea I had was to have a .VIRTUAL
> special target whose prerequisites would be targets whose timestamp
> would result newer than the parent's timestamp, if their action
> returned an exit value != 0, otherwise they would result older.
> 
> This might not sound very useful at a glance, but it would be really
> useful if .VIRTUAL's prerequisites could use stems.
> 
> Consider this case:
> 
> .VIRTUAL : MD5(%) CHECK_MD5(%)
> 
> CHECK_MD5(%) :
>         md5sum --check $*.md5 >/dev/null 2>&1
> 
> MD5(%) : CHECK_MD5(%)
>         md5sum -b $* > $*.md5
>         exit 1
> 
> file.c : MD5(header1.h) MD5(header2.h) MD5(header3.h) 
> 
> (You don't really need CHECK_MD5(%), an if statement could be used
> instead, but it's there to illustrate the functionality).

Exactly! You can already do this in a much more straightforward way.

Also see

http://kolpackov.net/pipermail/notes/2004-September/000011.html

> 
> What it does, is making file.c depend on header1.h, header2.h and
> header3.h, but rather than using their timestamps to check whether
> they've changed, it uses their md5 hash values. A feature, I hear,
> which is much requested.
> 
> Of course the idea is applicable to an infinite amount of other
> situations. Dunno how much feasible it would be, though.

I can't think of even one ;-). The example you presented above does 
not count since you can already do this (also your approach has
scalability problems - see link above).

Can you provide a non-academic example of where your logic is useful
which can't be done with current make functionality?

-boris

signature.asc
Description: Digital signature