On 02/07/18 13:58, Oliver Smith wrote:
> Hey Natanael,
>
> the list sounds good to me, especially the increased security
> features!
>
> While I agree with A. Wilcox that cross-compiling has the
> disadvantage of not running tests (or not properly if done through
> QEMU), I think it *does* make sense at least for kernels (there
> aren't any tests to execute for them). In my opinion, this is rather
> a detail, and the important thing would be getting everything else
> implemented first. With that being said: We have cross-compiling
> binary packages in the postmarketOS repo since we do lots of
> cross-compiling: gcc-armhf, binutils-armhf, musl-armhf etc. The
> aports for these are automatically generated from the upstream ones
> in Alpine (basically hardcoded variables from the bootstrap script on
> top). Unless the new build system would approach cross-compiling in a
> completely different way, you would also need such binary packages to
> do it, so maybe this feature can be upstreamed properly (that is the
> long-term plan anyway, if you guys want to have this - maybe with
> subpackages?).

I'm not sure what feature you are talking about. There is already
bootstrap.sh to generate a working cross environment. I suppose you
could make a bootstrap-lite.sh or such that only makes the toolchain and
none of the other components, which would work for a kernel build.

> Regarding caching: Maybe ccache makes sense, if it was separated for
> each package, and incoming pull-requests could only read from that
> cache, not write to it.

I think the cache point is more for the actual git data and distfiles,
not the compilation.

> Finally, I am not sure if the idea is to replace abuild entirely, or
> just abuild-rootbld.

Who said abuild was being replaced? This is about `buildrepo` and
friends, not abuild.

> In case abuild should be replaced, I hope to see
> the following features preserved (since we make use of them in
> pmbootstrap, which wraps abuild):
>
> - (passing through environment variables)

This isn't a wise idea. It's better to export them in the build() or
package() functions.

> - abuild -r (install depends with abuild)

This is currently how all Adélie packages are built, but it is a bit
buggy. It is useful for end users making single contributions, but
honestly, I think that this new system is going to be much better than
`abuild -r`.

> - abuild undeps

Due to the way abuild works right now, `apk del .makedepends-$pkgname`
has the same effect, if you ever need to do that without abuild. That's
an implementation detail and is not guaranteed to always work, but it
does work right now if you need it.

> - abuild menuconfig

??? This isn't even an abuild feature. It (ab)uses the fact that
abuild phases are shell functions by calling a menuconfig() function in
the kernel APKBUILD. Honestly, I would be much in favour of /not/
abusing that fact, and making abuild more hardened against that, but
that is just me.