Autoconf #292
Autoconf #292
Conversation
For some packages plain autoreconf doesn't work. Instead some `autogen.sh` or other scripts are provided by the package maintainer. For such packages `AUTOCONF_TOOL` can be used to override the default behavior.
Sometimes (when building from development sources) calling a bootstrap script is required prior to autoreconf. Add `AUTOCONF_BOOTSTRAP_TOOL` which can be set to e.g. `./bootstrap.sh` to be able to use the autoconf class for those packages.
| # Otherwise files may appear older than they are and trigger | ||
| # reconfigurations in the build step. | ||
| export TMPDIR="$BOB_CWD" | ||
| if [[ -n ${AUTOCONF_TOOL:-} ]]; then |
There was a problem hiding this comment.
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 foobarAutoconfThere was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
2 participants
No description provided.