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/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 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 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
[pacman-dev] interest in using meson over autotools?
Hi, I'm probably not the first to suggest that Autotools is slow and terrible, but here it is: Autotools is slow and terrible. Concretely, a few things I find highly annoying about our current use of Autotools: * We have to carry hacks to the build system itself just to ensure that our binaries aren't overlinked. * Data is duplicated across Makefiles -- derived path configurations such as LOCALEDIR or CONFFILE. * Code is duplicated across directories (symlinked to src/common). As a result, we have poor isolation and rebuild the code multiple times. * './configure && make -C src/pacman pacman' fails. It seems absurd that the user at the command line should have to know to build libalpm first. Isn't that the whole point of a dependency-tracking build system? Subjectively, the configuration itself is archaic and verbose. Does anyone *really* want to spend time understanding the quoting semantics of m4, or figure out where things like $ac_cv_sys_file_offset_bits come from? 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. Why meson? * It's fast. I wrote the initial meson.build files to compile libalpm.so and pacman (this took me under an hour). The resulting build takes 1/3 of the time of the equivalent autotools build. The ./configure equivalent in meson will be faster too, but I can't compare that yet because my meson-equivalent is incomplete. Trust me, it'll be faster. * It's modular. You can still constrain lots of subdirectory specifics in subdirectory meson.build files. * It's easy to read. The config is python-ish, and it's very concise. The documentation is comprehensive and has plenty of examples. * There's lots of upstream support, and the community is growing. In Arch Linux, 175 packages are built using meson (largely because gnome has decided to adopt meson). We would not be an early adopter of meson. * It's portable. meson supports all the targets where we currently have actual users. 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
Re: [pacman-dev] Add --nolist option for transactions
On 07/07/18 10:32, m...@dk0.us wrote:
> From: Dmitry Kudriavtsev
>
> Adds a --nolist option for package transactions. This option removes the list
> display of packages to be installed or removed.
>
> Signed-off-by: Dmitry Kudriavtsev
> ---
I don't think this is a good option to include.
> diff --git a/src/pacman/remove.c b/src/pacman/remove.c
> index a2269ed8..5df45c69 100644
> --- a/src/pacman/remove.c
> +++ b/src/pacman/remove.c
> @@ -164,8 +164,11 @@ int pacman_remove(alpm_list_t *targets)
> }
>
> /* print targets and ask user confirmation */
> - display_targets();
> - printf("\n");
> + if(!config->nolist) {
> + display_targets();
> + printf("\n");
> + }
> +
Here pacman would print nothing then ask if it is OK to remove those
packages.
> if(yesno(_("Do you want to remove these packages?")) == 0) {
> retval = 1;
> goto cleanup;
> diff --git a/src/pacman/sync.c b/src/pacman/sync.c
> index 3c6be89d..1e0c6c91 100644
> --- a/src/pacman/sync.c
> +++ b/src/pacman/sync.c
> @@ -793,8 +793,10 @@ int sync_prepare_execute(void)
> goto cleanup;
> }
>
> - display_targets();
> - printf("\n");
> + if(!config->nolist) {
> + display_targets();
> + printf("\n");
> + }
>
> int confirm;
> if(config->op_s_downloadonly) {
>
