Eric Blake <[EMAIL PROTECTED]> writes:
> According to Simon Josefsson on 12/17/2007 4:41 AM:
>>
>> My attempts to solve it (e.g., overwrite autopoint files with gnulib
>> files) caused unnecessary invocations of autoconf due to file time
>> changes, and I wasn't able to make it work smoothly.
>
> M4 head does it as follows:
>
> # Released autopoint has the tendency to install macros that have been
> # obsoleted in current gnulib, so run this before gnulib-tool.
> func_echo "running: $AUTOPOINT --force"
> $AUTOPOINT --force
>
> func_echo "running: ${GNULIB_TOOL} --update"
> ${GNULIB_TOOL} --update
>
> # Disable autopoint, since it was already done above.
> func_echo "running: AUTOPOINT=true" \
> "$AUTORECONF --force --verbose --install --no-recursive"
> AUTOPOINT=true $AUTORECONF --force --verbose --install --no-recursive
Problem is that I don't run gnulib-tool during the pre-configure stage,
gnulib files are stored in git for my projects.
I may reconsider if I see a solution for the problem of how to reproduce
the same gnulib files for ancient releases. I need the ability to check
out a year old version of our packages, and be able to build it using
the exact same gnulib files, to be able to release a security fixed
package with a minimal amount of changes. Given the API changes in
gnulib, I may not even be able to compile old code, let alone be able to
produce a security release that contains the minimum amount of necessary
changes.
/Simon
