Subject: bug#20699: Acknowledgement (subdir-objects with source from sibling directory breaks distcheck)

From: Hans-Bernhard Bröker <[email-masked]>
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.