Re: [pacman-dev] interest in using meson over autotools?
On 07/07/18 at 07:13pm, Dave Reisner wrote: > ... > Would there be interest in accepting patches to make these changes? I > propose we would carry both build systems in parallel for a major > release before eventually dropping autotools. > > Feedback wanted, > dR I've hated the experience every single time I've had to deal with our autotools setup, so I'm definitely open to change. Our test suite is currently integrated with it, though. What changes would we have to make to our tests for meson? apg
Re: [pacman-dev] interest in using meson over autotools?
On Sat, Jul 07, 2018 at 07:58:36PM -0400, Andrew Gregory wrote: > On 07/07/18 at 07:13pm, Dave Reisner wrote: > > ... > > Would there be interest in accepting patches to make these changes? I > > propose we would carry both build systems in parallel for a major > > release before eventually dropping autotools. > > > > Feedback wanted, > > dR > > I've hated the experience every single time I've had to deal with our > autotools setup, so I'm definitely open to change. Our test suite is > currently integrated with it, though. What changes would we have to > make to our tests for meson? > > apg This is one area where Meson could use some improvement. There's generic support for tests, but no specific support for tests using TAP. There's an open issue where someone explicitly has requested this: https://github.com/mesonbuild/meson/issues/2923 Towards the end, there's some suggested workarounds for the current limitations. I think the answer is ideally that we have no make no changes at all to our tests. We could do all of the work in the build system alone -- use a harness to wrap each test and parse the TAP output.
Re: [pacman-dev] interest in using meson over autotools?
On 08/07/18 09:13, Dave Reisner wrote: > Yes, some of this could be resolved by fixing/rewriting the autotools > madness to not use recursive make, but I'd suggest we just drop > autotools and adopt meson. Meson can easily fix all of the above. I had a branch on a old dead laptop that rewrote autotools stuff and fixed most of those issues. Also required some rearrangement of our code rather than symlinking shared stuff. Was still crap... Anyway, I have not had time to deal with meson, so I'll take your endorsement at face value. Happy to change, particularly if we plan for a release containing both as a transition. But I will likely need help reviewing meson related stuff until I get up to speed. A
Re: [pacman-dev] interest in using meson over autotools?
On 07/07/2018 07:13 PM, Dave Reisner wrote: > Would there be interest in accepting patches to make these changes? I > propose we would carry both build systems in parallel for a major > release before eventually dropping autotools. I want this and have suggested it recently on IRC. I think Allan may have suggested there were some gotchas for building statically? That's something I'd like to keep, mainly so https://aur.archlinux.org/packages/pacman-static continues to be a valid recovery option for people with borked systems. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] interest in using meson over autotools?
On 08.07.2018 02:07, Dave Reisner wrote: > I think the answer is ideally that we have no make no changes at all to > our tests. We could do all of the work in the build system alone -- use > a harness to wrap each test and parse the TAP output. You could also use perl's `prove` to run the tests. You'd probably need to create a wrapper script that handles running pacman tests though since those can't be executed directly like the shell tests. Basically you'd need to combine these two into one. Note that they are run from the respective test directories so the paths are all weird. prove -e 'python2 ./pactest.py --pacman ../../src/pacman/pacman' tests/sync*.py PMTEST_SCRIPTLIB_DIR=~/git/arch/pacman/scripts/library/ PMTEST_LIBMAKEPKG_DIR=~/git/arch/pacman/scripts/libmakepkg/ prove scripts/*.sh util/vercmptest.sh FWIW running the tests via those commands seems to work for me, but I don't know if this can be integrated into meson or if you want to use prove. Florian signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] interest in using meson over autotools?
On 07/08/2018 12:10 PM, Andreas Baumann wrote: > Hi, > > Sorry, if this message is a little bit out of order, I only just > subscribed to the pacman-dev group. It's simple to reply to an existing message, if you click on the email address of the sender which mailman turns into a mailto:u...@domain.com?Subject=foo&In-Reply-To= link -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] interest in using meson over autotools?
On Sun, Jul 08, 2018 at 06:10:09PM +0200, Andreas Baumann wrote: > Hi, > > Sorry, if this message is a little bit out of order, I only just > subscribed to the pacman-dev group. > > I want to raise the issue of bootstrapping: > - automake, autoconf, libtool and friends need m4 and perl and bash > - meson needs python > > Bootstrapping m4 and perl is comparatively easy to bootstrapping python. So then build a minimal python as a "stage 1". You only need libffi and expat, which themselves have no build dependencies beyond glibc. Upstream has heard this argument before, thus: http://mesonbuild.com/FAQ.html#why-is-meson-implemented-in-python-rather-than-programming-language-x http://mesonbuild.com/Use-of-Python.html > Porting to other architectures is easier if there are not too many > dependencies. > > See also my experiments here: > > https://git.archlinux32.org/archlinux32/bootstrap32 > > and some porting work from oaken-source (Parabola): > > https://github.com/oaken-source/parabola-riscv64-bootstrap I'm not sure exactly what I'm supposed to get out of these. The reality is that I don't really buy your argument. If you're bootstrapping Arch Linux, you need to build Python anyways. You'll have to build Meson in order to build systemd. You'll have to build Python in order to run pacman's unit tests (you should absolutely care about these for bootstrapping). Changing your bootstrap order to accomodate this doesn't really seem that onerous. > Cheers > > Andreas > > -- > Andreas Baumann > Trottenstrasse 20 > CH-8037 Zuerich > Telefon: +41(0)76/373 01 29 > E-mail: m...@andreasbaumann.cc > Homepage: www.andreasbaumann.cc
Re: [pacman-dev] interest in using meson over autotools?
On 07/08/2018 04:39 PM, Dave Reisner wrote: > On Sun, Jul 08, 2018 at 06:10:09PM +0200, Andreas Baumann wrote: >> Hi, >> >> Sorry, if this message is a little bit out of order, I only just >> subscribed to the pacman-dev group. >> >> I want to raise the issue of bootstrapping: >> - automake, autoconf, libtool and friends need m4 and perl and bash >> - meson needs python >> >> Bootstrapping m4 and perl is comparatively easy to bootstrapping python. > > So then build a minimal python as a "stage 1". You only need libffi and > expat, which themselves have no build dependencies beyond glibc. > > Upstream has heard this argument before, thus: > > http://mesonbuild.com/FAQ.html#why-is-meson-implemented-in-python-rather-than-programming-language-x > http://mesonbuild.com/Use-of-Python.html > >> Porting to other architectures is easier if there are not too many >> dependencies. >> >> See also my experiments here: >> >> https://git.archlinux32.org/archlinux32/bootstrap32 >> >> and some porting work from oaken-source (Parabola): >> >> https://github.com/oaken-source/parabola-riscv64-bootstrap > > I'm not sure exactly what I'm supposed to get out of these. The reality > is that I don't really buy your argument. If you're bootstrapping Arch > Linux, you need to build Python anyways. You'll have to build Meson in > order to build systemd. You'll have to build Python in order to run > pacman's unit tests (you should absolutely care about these for > bootstrapping). Changing your bootstrap order to accomodate this doesn't > really seem that onerous. Anyways I pointed out that meson has cross-compilation support, and cross-compilation is already in play, so this should not be onerous. He agreed that this makes bootstrapping no longer an issue. I'd actually forgotten that the testsuite was in python :D but bootstrapping generally means building a minimal system, often with tests disabled, sufficient to cleanly rebuild everything with tests re-enabled. So I'm not sure that itself was a blocker. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
