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 #14 received at 20699 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: Peter Rosin <peda <at> lysator.liu.se>, 20699 <at> debbugs.gnu.org
Subject: Re: bug#20699: Acknowledgement (subdir-objects with source from
 sibling directory breaks distcheck)
Date: Tue, 23 Jun 2015 01:03:20 +0200
Am 23.06.2015 um 00:05 schrieb Peter Rosin:
> On 2015-06-21 23:14, Hans-Bernhard Bröker wrote:
>> It's actually even a little worse:
>>
>> Any dependency on sources in another directory causes a simple "make clean" in one directory to erase _all_ object files on that other one, i.e. if docs/Makefile.am has
[...]
>> With consequences like that, I think the (all but forced, now) option "subdir-objects" needs to be reconsidered.

> Sibling directories of this main directory are supposed to be
> controlled by a makefile in that sibling directory

They are. In the project this occurred in, ./src (and subdirs therein) 
holds the the main program, while ./docs is contains the master 
documentation and tools to combine it with documentation fragments from 
multiple source code files, and convert that to multiple output formats.

Now one of the documentation builders wants to refer to the compiled 
version information, which is with the main source.

> (or by a makefile in
> a parent directory). Notice how the option is named *subdir*-objects
> (and not *sibling*-objects or something such) and ../foo is hardly a
> subdir.

Agreed, it's not.  But then why does option subdir-objects even affect 
the way it's treated?

Without it, the problematic rm ../src/*.o isn't generated, and the tool 
complains that the subdir-objects is about to be forced on me soon. 
That doesn't bode well.

> You are perhaps better off converting the project to use a single
> top level makefile instead of using a recursive build.

That would be rather a long stretch.  There's a lot more recursion than 
this, some of it conditional, and it's worked reasonably well now for 
decades.  Converting all that into a single top-level makefile would be 
quite a painful workaround.





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.