[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Accommodate non-recursive Automake in a less hacky way
From: |
Bruno Haible |
Subject: |
Re: Accommodate non-recursive Automake in a less hacky way |
Date: |
Wed, 15 Dec 2021 21:30:19 +0100 |
Jim Meyering wrote:
> Thanks a lot!
The core of the processing is still the build-aux/prefix-gnulib-mk
that you wrote.
I dared to document it and thus declare it "supported", because if
people encounter problems with specific modules, we can fix them
- either by recognizing more patterns in prefix-gnulib-mk,
- or by making use of %reldir%.
In theory we could remove prefix-gnulib-mk entirely and instead
place thousands of %reldir% and %canon_reldir% in the Makefile.am
section of the modules. This would grossly hamper maintainability.
But it shows that a combination of prefix-gnulib-mk (for general
patterns) and %reldir% (for special cases) will be sufficient to
handle problem reports.
> I want to switch every package for which I used the hacky way.
I'd like to hear about it, since then we can deprecate the
'non-recursive-gnulib-prefix-hack' module.
> Hoping we can remove the 'non-recursive-gnulib-prefix-hack' support
> code before too long.
As usual, before removing something, I plan to deprecate it (i.e.
gnulib-tool will emit a deprecation message when it is used) and
then wait for 1 or 2 years.
Bruno
- Accommodate non-recursive Automake in a less hacky way, Bruno Haible, 2021/12/15
- Re: Accommodate non-recursive Automake in a less hacky way, Bruno Haible, 2021/12/16
- Re: Accommodate non-recursive Automake in a less hacky way, Paul Eggert, 2021/12/16
- Re: Accommodate non-recursive Automake in a less hacky way, Bruno Haible, 2021/12/17
- Re: Accommodate non-recursive Automake in a less hacky way, Bruno Haible, 2021/12/18
- Re: Accommodate non-recursive Automake in a less hacky way, Bruno Haible, 2021/12/18