Hi,

I've been now working roughly few weeks and already come quite a long
way. Basically, I have cross-building of core APKBUILDs working, and we
have qemu-user emulated vserver for building.

However, native compile bootstrapping did introduce few additional
problems. And also the fact that emulation is slow, I'd like to do few
things to speed up things.

Basically, musl support is present in newest autotools and gnulib. But
many packages use old versions - or are even so old releases that those
are not used. This is way we had abuild do config.sub updating earlier.

We just also pushed abuild patch to set CLIBC always properly to help
with our libc variants. This is now set automatically from abuild.conf
CHOST (same applies to CARCH). This simplifies a bit some of the
APKBUILDs we have currently.

But seems we need to do additional hackery with autotools and gnulib,
so we'd like to ask feedback on the following things:

1) usage of config.cache

We'd like to start using config.cache in similar manner with sabotage.
That is we provide a fixed config.cache for autotools usage. This
speeds up ./configure, and in addition allows us to force certain
values to make sure e.g. gnulib behaves. This means we need to pass
--cache-file to ./configure. I'd prefer to point it
to /usr/share/abuild/config.cache that basically just does something
like:

source /usr/share/abuild/config.cache.$CARCH
source /usr/share/abuild/config.cache.$CLIBC

For reference, the sabotage config.cache template is at:
https://github.com/rofl0r/sabotage/blob/master/KEEP/config.cache

2) standard configure options

The above means we need update basically all of our autotools APKBUILDs.
We have options to:
 a) have a script to update APKBUILDs to standard autotools magic
 b) have abuild function to call ./configure
 c) export $abuild_configure_options

I'm personally leaning for a, or a+c. In any case, we should likely
move --prefix and other path related autotools defines, along with
--build, --host, --target and --with-sysroot here.

3) config.sub, config.guess updating

We previously patched abuild to go and update this to latest version
that support musl in post_unpack. But we are now thinking of reverting
this, and having abuild export "update_config_sub" or similar, that
could be called in prepare hook. This would make it more explicit for
the user that we are replacing these.

4) fixing embedded gnulib

Seems gnulib got musl support around 2012-06. But we again have the
same problem as with autotools. Only fraction of packages ship with new
enough gnulib. The nasty thing seems to be that we need to regenerate
configure if we update the in-tree gnulib copy. And that opens another
can of worms - how to update per-package autotools magic to work with
latest autotools. Sabotage seems to just manually fiddle with gnulib to
make it compile. Ideas here are welcome what to do.

---

As an afterthought. I noticed abuildhelper that frameworkizes
autotools. However, only audacity uses that. I personally would try to
have APKBUILDs not using that kind of frameworks. So if when we
implement 2) above would it make sense to convert audacity to that as
well, and remove abuildhelper?

- Timo




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---