Hi Collin, > How does this patch look?
This one looks good. Applied. Thanks! > 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. Nice. > 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? Sometimes maintains copy a macro from a .m4 file (that has an AC_PREREQ invocation) into their configure.ac file. They are not required to merge the resulting 2 AC_PREREQs together. > 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. Yep, that's a good way to test this situation interactively. Bruno
