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

Mathieu Lirzin <[email protected]>
Newsgroups gmane.comp.sysutils.automake.patches
Message-ID <[email protected]>
Hello Thomas,

Thomas Martitz <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.