bug-automake
[Top][All Lists]
Advanced

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

bug#20699: Acknowledgement (subdir-objects with source from sibling dire


From: Hans-Bernhard Bröker
Subject: bug#20699: Acknowledgement (subdir-objects with source from sibling directory breaks distcheck)
Date: Tue, 23 Jun 2015 01:03:20 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.0.1

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.






reply via email to

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