autoconf / update-config

[rhubert]

ATM we have many packages with more than 1 checkout variant leading to multiple checkout directories, e.g.:

buildall-aarch64/devel::host-compat-toolchain/python::python3-minimal dev/src/python/python3/3/workspace
buildall-aarch64/devel::sandbox/devel::bootstrap-sandbox/python::python3-minimal dev/src/python/python3/1/workspace
buildall-aarch64/devel::sandbox/python::python3-minimal dev/src/python/python3/2/workspace
buildall-aarch64/python::python3-minimal dev/src/python/python3/4/workspace

Even after making all checkoutTools weak (not sure if this is a good idea at all...) they still have different checkoutVariantIds, which is expected I think after reading the documentation once more...

The issue with this is IMO, that you can no longer edit the sources in a single directory and rebuild the software. But the only way out of this seams to copy the sources into the build workspace and apply the autoreconf stuff?
Reworking the autoconf/autotools classes this way would also help me a lot when using git repos instead of urlscms...

[jkloetzke]

I see your point but I've been reluctant so far to copy the code. There are a number of drawbacks:

• For huge packages like gcc, it creates a considerable overhead.
• It's hard to safely update the patched copy in the build workspace from the sources. An rsync -a --delete will remove created files. Without --delete, stale files may be left. Probably not a big deal, though.
• You don't see the fully patched sources any more with --checkout-only. That may be a problem for license compliance where you sometimes have to provide the full and corresponding source code. Again, not very convincing because the build scripts (aka the recipes) must be supplied as well.

But maybe this all pales in comparison to the useless multiple checkout variants. I thought they are less of a problem because they affect only 9 recipes in basement so far. Recipes in other layers should not be affected, right?

But the only way out of this seams to copy the sources into the build workspace and apply the autoreconf stuff?

I see no good other option either. The problem is that we need m4 and perl already to generate the autotools package. They are needed when running autotools as well. So it will inherently create those variants.

Reworking the autoconf/autotools classes this way would also help me a lot when using git repos instead of urlscms...

Well, then it may be the way to go. At least trying it out doesn't seem to hurt...

[rhubert]

FYI: I started working on this. But since it triggers a rebuild of nearly everything I think this should be merged together with #258 - so I'll come up with a suggestion for this as well...