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

Hello Thomas,

Thomas Martitz <[email protected]> writes:

> good news: I found a solution.

Great!  You have been fast.  :)

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

I am still busy, so I will need some time before being able to review
your patch seriously.  After the 4 may, I will have more time.  Anyone
wanting to help in the review process is of course welcome.

> From 8cd0a71abac70bbdcaac804dc7964fa9f34753a0 Mon Sep 17 00:00:00 2001
> From: Thomas Martitz <[email protected]>
> Date: Mon, 13 Mar 2017 12:41:59 +0100
> Subject: [PATCH 1/3] Shorter object file names under subdir-objects
>
> 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.
>
> But with subdir-objects this is unnecessary, since uniqueness of the object
> file names is already achieved by placing them next to the unique source files.
>
> 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).
>
> There is one exception to the above: if the same source file is linked to
> separate programs/libraries with per-executable flags and the
> programs/libraries have identical names, then uniqueness of truncated object
> file names is broken. Therefore the truncation is prevented for these targets
> if there happens to be identically named progams or libraries,
>
> 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
> ---
>  NEWS                        |   6 +++
>  bin/automake.in             |  90 ++++++++++++++++++++++++++++++++--
>  t/list-of-tests.mk          |   1 +
>  t/subdir-objects-objname.sh | 115 ++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 207 insertions(+), 5 deletions(-)
>  create mode 100644 t/subdir-objects-objname.sh

[...]

> From 5cf501dd932b4aabcc60b489e4f19c2ad8a757cc Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <[email protected]>
> Date: Thu, 13 Apr 2017 14:19:15 +0200
> Subject: [PATCH 2/3] Test that should pass.
> 
> The test ensures that programs with equal names get unique object files even
> if object file name truncation is in effect.
> ---
>  t/list-of-tests.mk        |  1 +
>  t/subobj-objname-clash.sh | 58 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 59 insertions(+)
>  create mode 100644 t/subobj-objname-clash.sh

[...]

> From 508b7e19745d88dbd1100b403fec440abfd151bb Mon Sep 17 00:00:00 2001
> From: Thomas Martitz <[email protected]>
> Date: Sat, 22 Apr 2017 00:51:44 +0200
> Subject: [PATCH 3/3] Extend subobj-objname-clash.sh test with such that it
>  also looks for clashes in libraries.
>
> ---
>  t/subobj-objname-clash.sh | 32 +++++++++++++++++++++++++++++---
>  1 file changed, 29 insertions(+), 3 deletions(-)

At first glance, I think it would be reasonable to reduce the 3 tests to
only 1 which checks that there is no name clash between multiple
_PROGRAMS and _LIBRARIES.

Can you send an updated patch which includes both your code and the
suggested test?

Thank you.

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