Subject: Re: [alpine-devel] rethinking the building infra
To: alpine-devel@lists.alpinelinux.org
References: <20180206013944.7fa393b6@ncopa-macbook.copa.dup.pw>
 <7676a963-d2b0-bf15-4f51-f5aa0d034e9a@bitmessage.ch>
From: "A. Wilcox" <awilfox@adelielinux.org>
Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?=
Message-ID: <290b7bc4-203d-dad4-21e5-3892537a2a76@adelielinux.org>
Date: Wed, 7 Feb 2018 14:33:42 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <7676a963-d2b0-bf15-4f51-f5aa0d034e9a@bitmessage.ch>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="xCkaaxTvuqoaxLJEFE0qfWGQiBSjlmbDv"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xCkaaxTvuqoaxLJEFE0qfWGQiBSjlmbDv
Content-Type: multipart/mixed; boundary="gxfuElKE4hQMhJThHMncRuQ2xAiLUQIV2";
 protected-headers="v1"
From: "A. Wilcox" <awilfox@adelielinux.org>
To: alpine-devel@lists.alpinelinux.org
Message-ID: <290b7bc4-203d-dad4-21e5-3892537a2a76@adelielinux.org>
Subject: Re: [alpine-devel] rethinking the building infra
References: <20180206013944.7fa393b6@ncopa-macbook.copa.dup.pw>
 <7676a963-d2b0-bf15-4f51-f5aa0d034e9a@bitmessage.ch>
In-Reply-To: <7676a963-d2b0-bf15-4f51-f5aa0d034e9a@bitmessage.ch>

--gxfuElKE4hQMhJThHMncRuQ2xAiLUQIV2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/07/18 13:58, Oliver Smith wrote:
> Hey Natanael,
>=20
> the list sounds good to me, especially the increased security
> features!
>=20
> 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=C3=A9lie 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=20

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.


Best,
--arw

--=20
A. Wilcox (awilfox)
Project Lead, Ad=C3=A9lie Linux
http://adelielinux.org


--gxfuElKE4hQMhJThHMncRuQ2xAiLUQIV2--

--xCkaaxTvuqoaxLJEFE0qfWGQiBSjlmbDv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJMBAEBCAA2FiEEjNyWOYPU1SaTSMHHyynLUZIrnRQFAlp7YqYYHGF3aWxmb3hA
YWRlbGllbGludXgub3JnAAoJEMspy1GSK50UNjkQAIXWr4Ak6wZBLP/Yt/qpKfvu
xL64IAah3I4m9LhRAjojb/ZZWaKhtQK/+ZiMuqDXs2COimaLGtcoy82I+mA/eOnC
cw3K8j2qpGjdf3//BKgTvDPf+vkjHM1DcAwSth24eArt93x7Mjl6qwbYOPg4MN7f
S277cp3fyzTzmZ+JvQEDxvE3YwUfixbjrnroL2SnL7z5KLIVpMKF2EGp0xNawttd
b+xFQ2Jmvt/Nm0kpduE+/Bx2VEqaM11667UUSiEIAbEK1IBHq26daNh6zAAzlbBo
IcsIZPXcd8XXBOOgYJLSsRhwL4mbRhDXiSJEjZsfjcaMRqxoWzLsQggQAvDwWiZj
4Y/Y0oHcfKxOMzi2V/q0Uj2L5JVHaAGov3aqbEum9BzNLnLGayHXjHCq3V/nY8Fl
SmLuhDbuRkGfGPZImT6V4gFhQtbfW4kV9osXJ3VdJjXLK17CYcp3Pqnz9uD/M94s
II6tc8YtooMr5p3QRFgyJxYKCnrHx1+85D5P4Wi4OZ/gZV9ExvqdtW7g3++aACI4
ssUoKyQZ723esU88YkDNwxiFn3by6CYXPKGse4OANe1JTZnXGSudTYd/gdhIwrkW
jgNDORkeRbx+MSb5GAfzqsS6Gheg9YbOu8sHEzW7IZPoIP9M7zPZHmxSjojQ2lZt
XAO4q39WEcmFmbWM2Eqz
=WZBM
-----END PGP SIGNATURE-----

--xCkaaxTvuqoaxLJEFE0qfWGQiBSjlmbDv--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---