Re: [PATCH v3] new option: object-shortname

[Mathieu Lirzin]

Hello Thomas,

Thomas Martitz <address@hidden> writes:

> Am 07.03.2017 um 18:44 schrieb Mathieu Lirzin:
>
>> Sorry, but I am still not convinced.  While I agree it is only a small
>> change regarding the amount of code, this new option has to be
>> documented and maintained.  Beyond optimizing the support of recursive
>> and non-recursive makefiles providing the same targets which is a hack
>> that can't reasonably be documented in Automake manual, I can't find a
>> reason to justify its presence.
>
> Alright, this makes me bitter, since I'm trying to get feedback on
> this for more than a year, and the previous indications seemed like
> the change would be OK (e.g. [1])

I fully understand how you can feel.

> Let me try to come from a different direction and completely ignore my
> use case. Even for normal, non-recursive use, Automake generates
> unwieldy long file names. Consider this:
>
> $ cat root/Makefile.am:
> AUTOMAKE_OPTIONS = subdir-objects
> include
> projects/fancy_product/lib/config_parser/test/regression_tests/Makefile.inc
>
> $ cat
> root/projects/fancy_product/lib/config_parser/test/regression_tests/Makefile.inc
>
> bin_PROGRAMS = helper
> helper_SOURCES = %D%/helper.c
> helper_CFLAGS = $(AM_CFLAGS)
>
>
> Running make generates:
> root/projects/fancy_product/lib/config_parser/test/regression_tests/projects_fancy_product_lib_config_parser_test_regression_tests_helper-helper.o
>
> This is completely unnecessary, as there is no chance that objects
> overwrite each other (due to subdir-objects, this is a problem with
> non-subdir-objects, if different subdirs have source files with the
> same name). It can also create real problems, which is why _SHORTNAME
> exists at all.
>
> It would be far more useful if objects would generally have shorter
> file names under subdir-objects,
> i.e. 
> root/projects/fancy_product/lib/config_parser/test/regression_tests/helper-helper.o
> (helper- prefix due to target specific CFLAGS).
>
> So if it's a problem to support this as an option, then I would like
> to ask to simply switch the generated file names unconditionally when
> subdir-objects is enabled (this was already suggested in [1]). I was
> afraid of changing any existing behavior, this is why I decided for a
> new opt-in behavior. But I don't think the object file names are
> documented such that they are not allowed to change. I would like to
> prepare that change if it's OK for you.

I have never considered that possibility.  :)

I have blindy supposed that there was a good reason for such long names
even with the 'subdir-objects' option on.  However intuitively I don't
see any potential issue, so unless I overlook something, I think such
change would be acceptable.

When I have some time, I will make some research in the mailing list
archives and in the git logs about potential known issues with this
approach.  I will let you know if I found any.

>> Having said that I would happily accept a patch that fixes the usage of
>> %C%, %D% in _SHORTNAME, which beyond the inconvenience of having to
>> define it for each program or library, would achieve your goal of not
>> compiling some files twice when invoking make in different locations.
>>
>
> This is truly very hard, maybe impossible. I have looked into it
> [1]. The core issue is that _SHORTNAME, unlike all other variables, is
> already evaluated when generating Makefile.in., as the make targets
> are already completed. Automake conditionals can only comment out
> lines in the Makefile, they cannot make complex changes like renaming
> make targets or dependencies or process recipes.
>
> It would be a major change, if possible at all, under the current
> architecture of Automake.

OK, thanks for investigating this.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37