Re: [PATCH] Shorter object file names under subdir-objects

[Mathieu Lirzin]

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 <address@hidden> 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