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

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:
>
>   https://lists.gnu.org/archive/html/automake/2013-02/msg00051.html
>   https://lists.gnu.org/archive/html/automake/2003-11/msg00104.html
>

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 <[email protected]> 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.


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


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


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