--- Begin Message ---
|
Subject: |
subdir-objects with source from sibling directory breaks distcheck |
|
Date: |
Sat, 30 May 2015 14:12:38 +0200 |
|
User-agent: |
Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
Hello everyone,
I'm just about to turn on option subdir-objects in project gnuplot, but
ran in to a snag. Make distcheck now fails in the distclean phase
because distclean in one subdirectory removes dependency files that
make, in another one, still needs.
The trigger was this in docs/Makefile.am:
doc2wxhtml_SOURCES = windows/doc2html.c ../src/version.c
doc2wxhtml_CPPFLAGS = -DALL_TERM_DOC -DWXHELP -I../src $(AM_CPPFLAGS)
The reference to windows/doc2html.c was what had me turn on
subdir-objects. The reference to a source file from a neighboring
../src directory triggers the breakage. All is well in typical
day-to-day operation, but since the distclean phase of a make distcheck
kills src/.deps before visiting docs, make in docs now dies:
Making distclean in docs
Makefile:592: ../src/.deps/doc2wxhtml-version.Po: No such file or directory
Tool versions: automake-1.14.1 and 1.15, autoconf-2.69, on current Cygwin.
I've attached a copy of amhello modified to trigger the bug.
amhello-1.0.tar.gz
Description: GNU Zip compressed data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#20699: bug#37499: Wrong location of deps directory when using AC_SUBST |
|
Date: |
Thu, 3 Dec 2020 15:03:59 -0700 |
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.
I agree. I added a caveat to the manual about the current behavior.
If that is impossible, that may mean the subdir-objects option is not
ready to be made the default, much less a non-option.
I agree. I made the warning less forceful ("may", deleted "unconditionally").
Maybe sources from directories that are not, in fact, subdirs should
simply be exempt from subdir-objects handling.
That does seem like it would have been a cleaner implementation. But
since it was not done that way originally, I do not want to change the
existing behavior at this late date. Experience teaches that any change
of longstanding behavior will likely cause problems in some existing
projects, even while improving others.
> affecting current Gnuplot adversely?
Not any more.
I'm glad to know you were able to work around it. I'm sorry it was necessary.
That says "will change" rather than "may change", and it says
"unconditionally". To me, that did read "forced on me, soon."
You're right that that was the implication. Looking at the comments, the
change was/is intended for Automake 2.0, though. It is not surprising it
did not happen quickly.
At this point, Jim and I are basically the only people making changes to
Automake, and neither I nor (as far as I understand it) he have time or
inclination to do substantial development. We just want to fix reported
bugs, to keep Automake alive.
Besides changing the warning text, I left a bug reference and comment in
the source about this change to unconditional subdir-objects being
problematic, for the benefit of future developments. (Personally, I
would never make such a change "unconditionally"; there should always be
a way to preserve existing behavior.)
I can't think of more to do here at present, so I'm tentatively closing
this bug. Feel free to send more if desired.
Thanks for all the info and patiently explaining the problem about
sixteen times :).
Karl
subobj.patch
Description: Binary data
--- End Message ---