[Top][All Lists]

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

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

From: Thomas Martitz
Subject: RFC Re: [PATCH] Shorter object file names under subdir-objects
Date: Sat, 22 Apr 2017 01:02:39 +0200

Hello Matieu,

good news: I found a solution.

Am 19.04.2017 um 12:54 schrieb Mathieu Lirzin:


Thomas Martitz <address@hidden> 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:

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

I agree that the way long object names appears can be confusing for
Automake users.

Thomas Martitz <address@hidden> 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
   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.

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.

I have implemented a solution. Basically the file name truncation is disabled if the are programs or libs that have identical names. Please tell me if that's sufficient.

Best ragerds.

Attachment: 0001-Shorter-object-file-names-under-subdir-objects.patch
Description: Text Data

Attachment: 0002-Test-that-should-pass.patch
Description: Text Data

Description: Text Data

reply via email to

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