automake
[Top][All Lists]
Advanced

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

Re: *_DATA primaries tried twice during make install?


From: Stepan Kasal
Subject: Re: *_DATA primaries tried twice during make install?
Date: Wed, 21 Sep 2005 11:10:40 +0200
User-agent: Mutt/1.4.1i

Hello,

On Tue, Sep 20, 2005 at 05:40:15PM +0200, Harald Dunkel wrote:
> *_DATA objects are verified on 2 paths:
> 
> 1) install-am -> all-am -> $(DATA) -> *_DATA
> 2) install-am -> install-data-am -> *_DATA
> 
> Any specific reason?

first, let me note that this is not specific to *_DATA, the same holds
for other primaries:

ad 1) The "install-am -> all-am" dependency causes everuthing to be checked.

ad 2) I see the fillowing dependencies in a Makefile.in:

install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
install-binPROGRAMS: $(bin_PROGRAMS)
install-libLTLIBRARIES: $(lib_LTLIBRARIES)

Actually, I see no strong reason for _any_ of these two dependencies:

ad 1)  Tom Tromey recently answered:

: > why does make install depend upon all?
: This is traditional; there is no hard requirement for it in the spec,
: it is just the "way things were done", at least in the GNU world as I
: understood it back then.

(http://lists.gnu.org/archive/html/automake/2005-09/msg00025.html)

ad 2)  I think that "make install" is percepted as a phony target which
installs what has been built by previous "make all".  So I see no strong
reason for the dependency install-binPROGRAM -> $(bin_PROGRAMS).

Actually, "make install" is usually done as root, and I don't want to
rebuild the target under root just because the dependencies are broken.
(I would suggest the following check instead: "make distcheck" would call
"make all" twice, and then verify that no file was changed.)

Please also note that removing the dependency 1) while keeping 2) would
be very dangerous.  If someone has the bad habit of running "make install"
without previous "make all", then they would now duild the whole project
via a path different from the usual one.  I guess this could bring some
hard-to-debug problems.

To conclude:  IMHO we could:
z) leave it as it is
a) remove dependency 2), for all primaries
b) like a), plus remove the install -> all dependency

Would anyone see any big problem with any of these alternatives?

> I had a phony target in the dependencies of an
> object in *_DATA, so I stumbled over this.

Well, I'm afraid this is not usually done.
The question is whether this problem is important enough to leave the
current status quo.  I'm not the one to decide this, nor I have any
strong opinion.

Just my $0.01,
        Stepan




reply via email to

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