[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mathieu Lirzin
Subject: Re: [PATCH] Shorter object file names under subdir-objects
Date: Thu, 13 Apr 2017 14:59:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

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:

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

> 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
  AUTOMAKE_OPTIONS = subdir-objects foreign
  noinst_PROGRAMS = foo
  foo_SOURCES = src/foo.c
  foo_CPPFLAGS = -DVAL=0
  include src/

  noinst_PROGRAMS += src/foo
  src_foo_CPPFLAGS = -DVAL=1
  src_foo_SOURCES = src/foo.c

  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/
>     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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]