Hello, Thomas Martitz <ku...@rockbox.org> writes:
> Am 13.04.2017 um 14:59 schrieb Mathieu Lirzin: > >> I have not spent a long time digging through the mailing list archive, >> There seem to have a lot of mail related to subdir-objects past bugs >> which makes it hard to find the information I am looking for. However I >> have found some questions which relates to the change you are proposing: >> >> https://lists.gnu.org/archive/html/automake/2013-02/msg00051.html >> https://lists.gnu.org/archive/html/automake/2003-11/msg00104.html >> > > Thanks for taking your time and digging through the archives. It looks > like there is a clear demand for the change (see also Peter Rosin's > reply). I agree that the way long object names appears can be confusing for Automake users. >> Thomas Martitz <ku...@rockbox.org> writes: >> [...] >>> But with subdir-objects this is unecessary, since uniqueness of the >>> object file names >>> is already achieved by placing them next to the unique source files. >> >> Unfornately, I have found an example which seems to contradict that >> assumption. >> >> Makefile.am: >> AUTOMAKE_OPTIONS = subdir-objects foreign >> noinst_PROGRAMS = foo >> foo_SOURCES = src/foo.c >> foo_CPPFLAGS = -DVAL=0 >> include src/local.mk >> >> src/local.mk: >> noinst_PROGRAMS += src/foo >> src_foo_CPPFLAGS = -DVAL=1 >> src_foo_SOURCES = src/foo.c >> >> src/foo.c: >> int >> main () >> { >> return VAL; >> } >> >> With the current behavior both "src/foo-foo.o" and "src/src_foo-foo.o" >> are produced which allows the two executables to refer to the correct >> VAL. However with the change you are proposing, only "src/foo-foo.o" is >> produced which is then used for both executables and make them return >> the same VAL. >> >> See attached patch for more details. It adds a test which passes on >> current 'minor' branch but fails when applied on top of your patch. The >> intent is to allow you to reproduce the issue. > > > The case you have brought up pretty much does the same as using %C% > inside local.mk. It's just that you manually applied src_ and src/ > prefixes manually. > > Therefore, yes, this is affected by my change. The code where my > change is located doesn't really know whether %reldir%-feature was > used, or if prefixes have been manually assigned. That code only sees > the already-expanded variables. > > I have to say that your example seems pretty academic to me. I doubt > that anyone builds two equally named binaries in practice. Normally > you would build programs with different names, in which case this > effect doesn't occur, wouldn't you? > > But please be sure that understand that you take this seriously. Out of context a lot of things can be seen as weird, but since having programs with the same name in different directories has been considered valid by Automake for ages, we should expect some users to rely on that behavior, and we don't want to break it. >> I don't know if this is feasible to only use long names when there is an >> executable or library basename clash. I suppose this would not be trivial to >> implement. WDYT? > > > I will certainly have a look at your suggestion. As an easy to > implement alternative, may I propose adding back the Automake option > (to opt-in in the new behavior), maybe with proposal to turn it on by > default with Automake 2.0 along with subdir-objects? That would be an easy alternative indeed. But as I already stated, I am not in favour of adding an option for this. However I am OK with changes that are transparent to the users, even if it requires extra work. :) > Perhaps we can find a description for the manual that makes you feel > less uneasy about maintainability? What do you think? I doubt rewording things in the manual could be done so that this option doesn't appear as a facility to achieve something similar to the discouraged _SHORTNAME with the extra possibility to combine it with %reldir%. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
