bug-gnulib
[Top][All Lists]
Advanced

[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

Attachment: 0001-gnulib-tool.py-Allow-the-use-of-both-configure.ac-an.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]