[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: Thomas Martitz
Subject: Re: [PATCH] Shorter object file names under subdir-objects
Date: Wed, 19 Apr 2017 10:10:48 +0200

Am 13.04.2017 um 14:59 schrieb 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:

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).

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

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

Yes, you seem to be right. %reldir% is just a method of applying directory-related name prefixes to targets names and source files.

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.

The case you have brought up pretty much does the same as using %C% inside 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.

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

    AUTOMAKE_OPTIONS = subdir-objects
    bin_PROGRAMS += %D%/foo
    %C%_foo_CFLAGS = $(AM_CFLAGS) -g

resulted in objects:

now object file name is:

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? Perhaps we can find a description for the manual that makes you feel less uneasy about maintainability? What do you think?

Best regards

reply via email to

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