[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...
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
- bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments, Bert Wesarg, 2013/03/11
- bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments, Stefano Lattarini, 2013/03/11
- bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments, Bert Wesarg, 2013/03/11
- bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments, Stefano Lattarini, 2013/03/11
- Message not available
- bug#13928: VPATH issues with subdir-objects (was: [PATCH 1/2] preproc: add support for relative names in included fragments), Stefano Lattarini, 2013/03/11
- bug#13928: VPATH issues with subdir-objects (was: [PATCH 1/2] preproc: add support for relative names in included fragments), Nick Bowler, 2013/03/11
- bug#13928: VPATH issues with subdir-objects, Stefano Lattarini, 2013/03/11
- bug#13928: VPATH issues with subdir-objects,
Nick Bowler <=
- bug#13928: VPATH issues with subdir-objects, Bert Wesarg, 2013/03/12