Hello Thomas, 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 Thomas Martitz <ku...@rockbox.org> writes: > Mathieu, based on your reaction on the other thread, I reworked my patch. > > This supersedes my other patch, "[PATCH] new option: > object-shortname". It is functionally the > same but does not introduce a new option, but ties the behavior to > subdir-objects instead. In > addition I made an additional bug fix and extended the test suite. > > Please merge. > Commit message follows: > > With the %reldir% feature, object file names can become very long, > because the file names > are prefixed with the %canon_reldir% substitution. The reason is to > achieve unique object > file names when target-specific CFLAGS or similar are used. When > subdir-objects is also > in effect, these long file names are also placed in potentially deep > subdirectories. IIUC The long object names (including the canonicalized directory name) are not related to the use of %reldir%, it just appears when combining 'subdir-objects' with compilation flags for non toplevel executables or libraries. > 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. > Therefore, this changes strips paths components, that are caused by > %canon_reldir% or > otherwise, from the object file names. The object file name is > prefixed by the target in > case of target-specific CFLAGS. As a result, the build tree looks less > scary and many > cases where $var_SHORTNAME was necessary can now be avoided. Remember > that the use of > $var_SHORTNAME is discouraged (and is not always an option since it > does not work inside > conditionals). > Example: > previously: > sub/Makefile.am: > AUTOMAKE_OPTIONS = subdir-objects > bin_PROGRAMS += %D%/foo > %C%_foo_CFLAGS = $(AM_CFLAGS) -g > > resulted in objects: > sub/sub_foo-foo.o > > now object file name is: > sub/foo-foo.o 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? Thanks and sorry for the long delay. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37