[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC Re: [PATCH] Shorter object file names under subdir-objects
From: |
Mathieu Lirzin |
Subject: |
Re: RFC Re: [PATCH] Shorter object file names under subdir-objects |
Date: |
Sun, 23 Apr 2017 18:39:49 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hello Thomas,
Thomas Martitz <address@hidden> 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 <address@hidden>
> 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 <address@hidden>
> 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 <address@hidden>
> 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