Skip to content

Autoconf #292

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
rhubert wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Autoconf #292

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
978b1c9
classes/autoconf: add option to call custom auto(re)conf tool
rhubert Jan 21, 2026
31c8bbb
classes/autoconf: optionally call bootstrapping tool
rhubert Jan 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 27 additions & 22 deletions classes/autoconf.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,31 +56,36 @@ buildSetup: |

if [[ ( ! -e configure ) || ( ! -e .autoreconf.stamp ) ||
( configure.ac -nt .autoreconf.stamp ) ]] ; then
(
# Work around a stupid perl limitation that does not retain
# sub-second file timestamps when moving files across file
# system boundaries. Make sure rename() always works.
# Otherwise files may appear older than they are and trigger
# reconfigurations in the build step.
export TMPDIR="$BOB_CWD"
${AUTOCONF_BOOTSTRAP_TOOL:-}
if [[ -n ${AUTOCONF_TOOL:-} ]]; then
Copy link
Member

@jkloetzke jkloetzke Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about passing the tool as option to the function? This variable is inconsistent to the other options available so far...

Also the AUTOCONF_BOOTSTRAP_TOOL could be subsumed by this option. You could pass a local function name as AUTOCONF_TOOL that could do the bootstrap as well:

foobarAutoconf()
{
    ./bootstrap.sh
    ./autogen.sh
}

autoconfReconfigure -t foobarAutoconf

Copy link
Contributor Author

@rhubert rhubert Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wouldn't work for me. I have another change to support building from development sources added in https://github.com/BobBuildTool/basement/blob/master/classes/autotools.yaml#L65

    # if the source folder did not contain configure but configure.ac we                      
     # call autoconfReconfigure to generate configure.                                         
     if [[ -e $1/configure.ac || -e $1/configure.in ]] && [ ! -e $1/configure ]; then          
         AUTOCONF_SYNC_RECONFIGURE=1                                                           
     fi

making the autoconfReconfigure being called from the autotoolsBuild call. If special bootstrapping is required I only have to add

AUTOCONF_BOOTSTRAP_TOOL="./bootstrap.sh" \
autoconfBuild ...

which usually doesn't conflict to other upstream changes... Following your suggestion I'd have to add an additional argument to autotoolsBuild as well.

Copy link
Member

@jkloetzke jkloetzke Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, what about making the recipes work with tarballs and git/development sources? If configure is not present, some magic must happen. What magic that is exactly could be put in the recipe. That would minimize the diff on your side and feel less "magic". Do you think this is feasible?

Having magic variables in the class that nobody understands for what they are used makes it hardly maintainable. In the best case, one could even switch the affected recipes to their public git repository and verify that build from development sources still works.

Copy link
Contributor Author

@rhubert rhubert Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a great idea and would indeed minimize the diff on my side.

A recipe would then look like:

# prepare development sources
if [ ! -e $1/configure ]; then
 autoconfSync $1 src
 pushd src
 ./bootstap.sh
 autoconfReconfigure
 pop
fi
# end prepare development sources

? this would also mean to inherit the autoconf class in many, maybe all autotools based recipes.

In the best case, one could even switch the affected recipes to their public git repository and verify that build from development sources still works.

You mean to have conditional checkouts to switch between development and released sources using something like BASEMENT_USE_DEV_SOURCES? Or would you prefer a individual switch for each package? This would make it 'hard' to test all the combinations...

Copy link
Member

@jkloetzke jkloetzke Jan 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A recipe would then look like:

# prepare development sources
if [ ! -e $1/configure ]; then
 autoconfSync $1 src
 pushd src
 ./bootstap.sh
 autoconfReconfigure
 pop
fi
# end prepare development sources

? this would also mean to inherit the autoconf class in many, maybe all autotools based recipes.

My hope would be to be able to put most of the logic into the autotools class in autotoolsBuild. And if some package needs to deviate from the default, there would be some options to autotoolsBuild to handle that...

You mean to have conditional checkouts to switch between development and released sources using something like BASEMENT_USE_DEV_SOURCES? Or would you prefer a individual switch for each package? This would make it 'hard' to test all the combinations...

No, not even conditional checkouts. Maybe some override files with a (long) list of overrides? But I guess even this is just nice to have because switching to git repos will be tested extensively for the affected recipes on your side.

${AUTOCONF_TOOL}
else
(
# Work around a stupid perl limitation that does not retain
# sub-second file timestamps when moving files across file
# system boundaries. Make sure rename() always works.
# Otherwise files may appear older than they are and trigger
# reconfigurations in the build step.
export TMPDIR="$BOB_CWD"

# We don't want to retain any backups. Give them a unique
# suffix so that they can be garbage collected.
export SIMPLE_BACKUP_SUFFIX=.bob-backup
# We don't want to retain any backups. Give them a unique
# suffix so that they can be garbage collected.
export SIMPLE_BACKUP_SUFFIX=.bob-backup

# Autoreconf will not replace existing autoconf-archive macros
# in the m4 directory. If that is needed, the recipe must
# force the update.
if [[ $CALL_ACLOCAL ]] ; then
if [[ -n "${ACLOCAL_ARGS[@]:+set}" ]] ; then
aclocal "${ACLOCAL_ARGS[@]}"
else
aclocal -I m4 --install
# Autoreconf will not replace existing autoconf-archive macros
# in the m4 directory. If that is needed, the recipe must
# force the update.
if [[ $CALL_ACLOCAL ]] ; then
if [[ -n "${ACLOCAL_ARGS[@]:+set}" ]] ; then
aclocal "${ACLOCAL_ARGS[@]}"
else
aclocal -I m4 --install
fi
fi
fi
autoreconf -v ${AUTORECONF_FORCE:+-fi} \
${AUTOCONF_EXTRA_PKGS[@]+"${AUTOCONF_EXTRA_PKGS[@]/#/-I}"}
)
autoreconf -v ${AUTORECONF_FORCE:+-fi} \
${AUTOCONF_EXTRA_PKGS[@]+"${AUTOCONF_EXTRA_PKGS[@]/#/-I}"}
)
fi
rm -rf autom4te.cache
find . -name '*.bob-backup' -delete
touch .autoreconf.stamp
Expand Down