[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20699: bug#37499: Wrong location of deps directory when using AC_SUB
From: |
Karl Berry |
Subject: |
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