GNU bug report logs - #20699
subdir-objects with source from sibling directory breaks distcheck

Previous Next

Package: automake;

Reported by: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>

Date: Sat, 30 May 2015 18:10:04 UTC

Severity: normal

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 20699 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: Karl Berry <karl <at> freefriends.org>, 20699 <at> debbugs.gnu.org
Subject: Re: bug#20699: bug#37499: Wrong location of deps directory when using
 AC_SUBST
Date: Wed, 2 Dec 2020 02:10:40 +0100
Am 29.11.2020 um 03:46 schrieb Karl Berry:

> Looking at 20699, as usual, I'm confused. Sorry. It seems like Automake
> is just following instructions. The docs/Makefile.am declares a
> dependency on ../src/main.c, so it removes ../src/*.o. How could it
> guess otherwise? 

Guessing shouldn't be involved.  Either source files like this, which 
lie outside the subtree of the current Makefile.am, should either be 
documented as frowned upon, or they must be treated correctly.  To be 
treated correctly, IMHO they must avoid breaking the distcheck target.

If that is impossible, that may mean the subdir-objects option is not 
ready to be made the default, much less a non-option.

> It does not seem feasible or desirable to somehow compute that
> ./src/whatever is not technically a "subdirectory" and therefore have
> subdir-objects do nothing with those files. And only for the clean
> targets? I can't wrap my head around this.

Maybe sources from directories that are not, in fact, subdirs should 
simply be exempt from subdir-objects handling.  Or if they do get that 
handling, then their object files would have to be put into cleverly 
named artificial subdirs of the individual build dir.  From there they 
can be cleaned without affecting other SUBDIRS of the main project.

> Let me step back and ask more generally: Is there some behavior in
> current Automake (1.16.3) which is affecting current Gnuplot adversely?

Not any more.  We had to work around it, and mangaed to do so by 
changing the method of version number provisioning from a generated 
source file to AC_SUBST()ed preprocessor definitions.

>    the tool complains that the subdir-objects is about to be forced on me
>    soon. That doesn't bode well.
> 
> Well, I agree, but:
> 
> 1) what tool? Automake? And "forced" how?

If I try to turn off subdir-objects right now, while there are some 
other, genuine subdir source dependencies in some Makefile.am, Automake 
1.16.1 tells me this:

automake-1.16: warning: possible forward-incompatibility.
automake-1.16: At least a source file is in a subdirectory, but the 
'subdir-objects'
automake-1.16: automake option hasn't been enabled.  For now, the 
corresponding output
automake-1.16: object file(s) will be placed in the top-level directory. 
 However,
automake-1.16: this behaviour will change in future Automake versions: 
they will
automake-1.16: unconditionally cause object files to be placed in the 
same subdirectory
automake-1.16: of the corresponding sources.
automake-1.16: You are advised to start using 'subdir-objects' option 
throughout your
automake-1.16: project, to avoid future incompatibilities.

That says "will change" rather than "may change", and it says 
"unconditionally".  To me, that did read "forced on me, soon."  I just 
over-estimated the "soon" aspect by a couple of years.




This bug report was last modified 4 years and 173 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.