[Top][All Lists]

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

bug#13928: VPATH issues with subdir-objects

From: Nick Bowler
Subject: bug#13928: VPATH issues with subdir-objects
Date: Tue, 12 Mar 2013 10:09:29 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On 2013-03-11 23:27 +0100, Stefano Lattarini wrote:
> On 03/11/2013 10:33 PM, Nick Bowler wrote:
> > On 2013-03-11 21:55 +0100, Stefano Lattarini wrote:
> > [...]
> >>   - from Automake 2.0 onward, only enable the automatic dependency
> >>     tracking if GNU make is used; we can thus assume the presence
> >>     of the "-include" directive
> >>
> Actually, to be more precise, we could simply test at runtime if that
> directive is supported by the target make implementation (there is
> already code that does so for the "include" directive, so we shouldn't
> need any real new code or logic); or at least, if some equivalent
> directive is available.  If yes, we can enable automatic dependency
> tracking (without having to worry about the GNU vs. non-GNU make issue
> at all).  But sadly, it appears that in practice GNU make is the only
> make flavor to actually implement this kind feature so far :-/ so all
> of this is moot.

FWIW, I believe that NetBSD make supports -include as well.

> > Particularly if those users are running on an exotic platform
> > without GNU make
> >
> <complain-mode>
>   Which makes me ask again, as I've done many times already: does such
>   platforms truly exist, and if yes, are they really relevant and
>   worth bending over backwards for?
> </complain-mode>

A platform on which GNU make does not run at all?  Probably not, as
GNU make itself is very portable.  But platforms which do not have it
installed by default are easy to find: FreeBSD, for example.

More importantly, the problems caused by incomplete make dependencies
may not be obvious as an error when building the package: it's entirely
possible that the package will build successfully, but incompletely,
after modifying the sources, only causing incorrect behaviour later
when the program is run.

> > Ideally, we should try to fix the bug before ripping out an
> > otherwise-working feature.
> If someone volunteers to write a patch for such a fix, I certainly won't
> object to it.  But I'm not going to do it myself anytime soon (and likely,
> not even anytime later).

Regarding the actual bug: without knowing much (yet!) about the relevant
Automake internals, I'm a bit surprised that

  src = src
  foo_SOURCES = $(src)/foo.c

fails with subdir-objects, but on the other hand

  src = src/foo.c
  foo_SOURCES = $(src)

seems to work just fine...

Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

reply via email to

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