[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnulib-tool.py: Only process configure.ac once.
From: |
Collin Funk |
Subject: |
Re: [PATCH] gnulib-tool.py: Only process configure.ac once. |
Date: |
Tue, 26 Mar 2024 15:57:20 -0700 |
User-agent: |
Mozilla Thunderbird |
Hi Bruno,
On 3/26/24 4:46 AM, Bruno Haible wrote:
> The original code looked out for multiple AC_PREREQ invocations and
> took the maximum. For example:
> AC_PREREQ([2.64])
> AC_PREREQ([2.69])
> AC_PREREQ([2.66])
> must be treated as if it were
> AC_PREREQ([2.69])
> The new code looks at the first AC_PREREQ invocation only.
Ah, I see. I didn't notice this for some reason. Is there a reason why
there might be multiple?
Usually when I used Autoconf I would just keep one at the top in sync
with whatever was in Debian GNU/Linux Stable at the time. Seemed to
work well for me. :)
> * The --automake-subdir/--automake-subdir-tests handling is specific
> to the 'import', 'add-import', 'remove-import', 'update' modes. It
> therefore belongs in GLImport.py. It does not belong in main.py.
I think that that I misunderstood this:
if case "$mode" in import | add-import | remove-import | update) true;; *)
false;; esac \
&& test -n "$destdir"; then
conditional and the if .. else indentation which lead to many of the
following issues. Sorry about that...
> The only problem that should be fixed is the determination of the file
> name of configure.ac/in, since that is currently duplicated code between
> main.py and GLImport.py.
How does this patch look?
An unintended side effect is that the './configure.ac' and
'configure.ac' disagreement in that gnulib-comp.m4 comment is also
fixed. The GLConfig.py change is not needed.
> A new test case is not needed. Test cases are needed, in general, for
> functionality that is
> - essential to many users, or
> - implemented in a complicated way, or
> - likely to be broken through future maintenance.
> The configure.in filename handling does not match either of these three
> criteria.
That makes sense. I agree that it is not likely to be broken.
Here is how I tested it in case you would like to confirm:
$ gnulib-tool.py --create-testdir --dir test-dir readme-release
$ cd test-dir
$ gnulib-tool.py --import readme-release
$ mv configure.ac configure.in
$ gnulib-tool.py --import readme-release
$ mv configure.in configure-missing.ac
$ gnulib-tool.py --import readme-release
/home/collin/.local/src/gnulib/gnulib-tool.py: *** cannot find configure.ac -
make sure you run gnulib-tool from within your package's directory
/home/collin/.local/src/gnulib/gnulib-tool.py: *** Stop.
Collin
0001-gnulib-tool.py-Allow-the-use-of-both-configure.ac-an.patch
Description: Text Data
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., (continued)
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., Bruno Haible, 2024/03/19
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., Collin Funk, 2024/03/19
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., Bruno Haible, 2024/03/19
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., Collin Funk, 2024/03/19
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., Bruno Haible, 2024/03/19
- Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67., Bruno Haible, 2024/03/20
Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 66., Bruno Haible, 2024/03/19
Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 65., Bruno Haible, 2024/03/19