Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2023-04-23 Thread Panu Matilainen
Since then we've adopted cmake. As with anything, it has its pros and cons, for 
us the primary pro was that almost all neighboring projects are using cmake.

And no, we will not reconsider switching build systems again anytime soon 
:laughing: 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-1519415913
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2023-04-22 Thread Eli Schwartz
> It would be very nice to have a meson reimplementation in C too, as meson is 
> careful to ensure the language definition isn't tied to python. There is 
> apparently some project out there which tried to take a stab at this... 
> reportedly... but the meson developer didn't remember anything more than that 
> when I asked.

These days, this is in our FAQ: 
https://mesonbuild.com/FAQ.html#but-i-really-want-a-version-of-meson-that-doesnt-use-python

boson is what I was thinking of, but its energy petered out before getting 
production-ready -- possibly because it got used as the basis of muon, which 
eventually extensively rewrote everything it inherited from boson.

Two years later, and muon is in a pretty solid place. Version 0.2.0 is out now, 
it is packaged in a couple of distros, and implements more or less everything 
you need to handle C/C++ projects. It's still missing support for most of 
meson's modules system, but I doubt you need cuda, qt, icestorm, etc. support...

I successfully built this PR with muon after adding a single tiny patch to make 
the po/ directory optional, since muon doesn't yet implement the i18n module. 
Perhaps someone would like to implement that in muon, it should suffice to add 
.po -> .mo support without maintainer targets...

You can get muon here: https://sr.ht/~lattis/muon/

muon dependencies for bootstrap:
- sh
- cc (with c99 support)

optional:
- pkgconf (for dependency support)
- libcurl (for subproject wrap support)
- libarchive (for subproject wrap support)

stage2 bootstrap + runtime dependencies:
- samurai, to actually build stuff :D

You definitely want pkgconf, but the bootstrap chain here is really quite 
excellent and no python is involved anywhere. :)

@pmatilai, is this worth reconsidering?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-1518929648
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-06-02 Thread Panu Matilainen
Closed #1209.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#event-3397804242___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-06-02 Thread Panu Matilainen
Lest anybody think this is still open for debate, I'm closing this now.

The landscape is slowly, slowly changing of course and at the time we're about 
to become the last autotools dinosaur on the boostrap field then we can look at 
the situation again.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-637561164___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-06-02 Thread ニール・ゴンパ
CMake is not required to bootstrap _openSUSE_. It is required for all other 
ones using a libsolv-based package manager. RHEL/Fedora, OpenMandriva, Photon, 
etc. require the package manager in the bootstrap cycle, so libsolv is part of 
the bootstrap, which means CMake is already there.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-637533869___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-06-02 Thread Dominique Leuenberger
> That said, if people _really_ think Python is a problem, I'm all in favor of 
> CMake here. The rest of the package manager stack maintained in this 
> organization uses it. Heck, openSUSE's Zypper uses it!

Weak argument: libzypp/zypper are not needed to bootstrap a distro (but we 
already have to build cmake twice anway to get out of a cycle due to cmake 
linking libcurl - but cmake further requries libuv and rhash)

if I could choose, I'd prefer meson of cmake

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-637522500___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-11 Thread Karel Zak
Note that "meson in util-linux" is an experimental project for now and if it 
will be merged upstream then we will not drop autotools at the same time. We 
definitely need extra time for distros to adopt.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-626558201___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-09 Thread ニール・ゴンパ
In general, I consider Python to be not as problematic of a base dependency as 
the dependencies for autotools, which are the following:

* bash
* m4
* perl (!!!)
* help2man
* make
* texinfo (!!!)

Now of course, most of this is hidden from you because autotools output is 
stored in source tarballs released by projects (including rpm). In _that_ 
scenario, you just need POSIX shell, make, and libtool.

That said, if people _really_ think Python is a problem, I'm all in favor of 
CMake here. The rest of the package manager stack maintained in this 
organization uses it. Heck, openSUSE's Zypper uses it! Debian's apt uses it too 
(they switched from their crazy half autotools half plain make system to CMake 
~3 years ago).

The ergonomics of CMake are well-known at this point (thanks to KDE and 
friends) and it's relatively trivial to bootstrap for builds. The portability 
of CMake is so much better than Autotools as well. CMake is also highly well 
supported in IDEs and text editors on all major platforms and several minor 
ones.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-626266937___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Eli Schwartz
>  >   * ninja
> 
> Easy-peasy, C++.

[samurai](https://github.com/michaelforney/samurai) is c99, even easier, and 
doesn't rely on re2c at all. It builds with a Makefile (although I understand 
that since python is already included, building ninja with configure.py isn't a 
huge dealbreaker).

It would be very nice to have a meson reimplementation in C too, as meson is 
careful to ensure the language definition isn't tied to python. There is 
apparently some project out there which tried to take a stab at this... 
reportedly... but the meson developer didn't remember anything more than that 
when I asked.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-626025487___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Dominique Leuenberger
> @DimStar77 ,
> 
> > Just to chime in here as well: openSUSE has the 'distro bootstrap' split 
> > and tries to keep it under control. It's right that python3 is already in 
> > that chain (we build python3 is a minimal set with as few deps as possible, 
> > and an enhanced set, in two runs)
> 
> I am curious, what depends on it apart from glibc (I guess)?

so far, glibc is the only python3(base) consumer (and I was not happy when the 
started - but our arguments were dismissed by the glibc maintainers back then 
too)

> > meson
> 
> If you have Python, no other deps.

Yep.. that does not sound scary (as long as one does not care for meson's test 
suite!)

> > ninja
> 
> Easy-peasy, C++.

'almost is everything turns out to be easy' - yet, one also wants to keep it 
small to get a bootstrap cycle.

> > re2c
> 
> Technically this is optional since ninja ships pre-generated sources.

Definitively not what we aim for. vendored-in sources is the wrong solution to 
any problem. For the same reason as most distros stopped linking everything 
statically. 

Preferably, the goal is to eliminate something out of the ring for something 
else coming in. That would be the optimal case. The more there is in the 
bootstrap cycle, the worse it gets on ABI changs if you take care of a distro 
that's is self-contained

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625912336___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Igor Raits
@DimStar77 ,

> Just to chime in here as well: openSUSE has the 'distro bootstrap' split and 
> tries to keep it under control. It's right that python3 is already in that 
> chain (we build python3 is a minimal set with as few deps as possible, and an 
> enhanced set, in two runs)

I am curious, what depends on it apart from glibc (I guess)?

> meson

If you have Python, no other deps.

> ninja

Easy-peasy, C++.

> re2c

Technically this is optional since ninja ships pre-generated sources.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625898177___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Dominique Leuenberger
Just to chime in here as well: openSUSE has the 'distro bootstrap' split and 
tries to keep it under control. It's right that python3 is already in that 
chain (we build python3 is a minimal set with as few deps as possible, and an 
enhanced set, in two runs)

I made a quick check as to what that would mean for our setip if rpm were to 
switch to meson. We'd need:

* meson (obvious)
* ninja
* rec2c

as new packages in ring0 (which currently consistes of 119 packages)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625859974___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Fabian Vogt
> Besides the tests, and the fact that autotools is the devil I know and 
> prefer, rpm sits really early in the bootstrap chain, and adding significant 
> extra burden there is not acceptable. If glibc or gcc adopt some 
> non-autotools based build-system, I'm willing to reconsider.

glibc already [needs Python 3 to 
build](https://sourceware.org/git/?p=glibc.git;a=blob;f=INSTALL;h=b7676d1c9f868e7b98bc4558349056d062182661
), so it's almost there...

I do also think that being able to bootstrap easily is a very important 
property though.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625831438___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread ニール・ゴンパ
@pmatilai Well this is really a downer...

I was considering doing a CMake port for the rpm build scripts for similar 
reasons to @ignatenkobrain's to Meson. But if you're going to say that no work 
is going to be accepted ever, then that means my suffering for trying to 
bootstrap autotools on macOS every time I need to set up builds of rpm is not 
meaningful to you either.

Between CMake or Meson, I would slightly prefer CMake, but both are orders of 
magnitude easier to deal with than Autotools on macOS.

(As for @mlschroe's point about build cycles... Sorry, you're going to have to 
get over that pretty soon. util-linux is changing over, as are several other 
core projects.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625797509___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread ニール・ゴンパ
@pmatilai Well this is really a downer...

I was considering doing a CMake port for the rpm build scripts for similar 
reasons to @ignatenkobrain's to Meson. But if you're going to say that _no_ 
work is going to be accepted ever, then that means my suffering for trying to 
bootstrap autotools on macOS every time I need to set up builds of rpm is not 
meaningful to you either.

Between CMake or Meson, I would _slightly_ prefer Meson, but _both_ are orders 
of magnitude easier to deal with than Autotools on macOS.

(As for @mlschroe's point about build cycles... Sorry, you're going to have to 
get over that pretty soon. util-linux is changing over, as are several other 
core projects.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625797228___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Panu Matilainen
There's always busybox if util-linux goes crazy...

Oh and @ignatenkobrain , this is nothing at all like support for a new 
signature type. Signatures are used / affect potentially millions of users out 
there, whereas there's only a handful of people in the world who actually need 
to build rpm from source tarballs, and even fewer people who need to actually 
need to build from git checkout and even fewer who actually need to modify the 
build system, which is the pain point of autoconf. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625775582___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Michael Schroeder
(But I admit that this point is moot if util-linux really switches to meson. 
Systemd is currently not a problem, as it is not needed for building.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625726930___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Michael Schroeder
No, Panu is right. Rpm being behind python *is* an issue for distribution 
builders because it introduces a nasty dependency cycle. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625719009___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Panu Matilainen
> Wish I'd know this earlier :)

Which is why I made a point of correcting it ASAP once I saw this effort to 
prevent any further wasted effort. I'm really sorry about that. My own 
recollection of the topic is simply that I've said "no" to suggestions of build 
system change that the point should be clear. But then I see I've left the door 
open contrary to my actual intentions :(

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625718766___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Zbigniew Jędrzejewski-Szmek
I think switching to a better build system is a worthwhile goal. Every switch 
to meson that I have seen has worked out well and was definitely worth the 
work. Apart from the speed and number-of-lines benefits that Igor listed, there 
are less tangible but important benefits that come from a better configuration 
language and more control over the configuration results. The logic expressed 
in meson can be much more elaborate when needed, because we have something that 
is a normal programming language, so 
build-this-if-that-and-that-but-not-the-other-thing becomes possible to express 
in a way that is understood by any contributor to the project, not just 
macro-m4-shell-automake wizards. And obviously, the relatively simple cases 
become much clearer too. All this lowers the bar for contribution.

Meson also allows more precise interaction with the code. A simple but 
illustrative case is the ability to switch from `#ifdef HAVE_` to `#if HAVE_`. 
(Autotools uses `#define HAVE_FOO 1`/`#undef HAVE_FOO` in most cases, except 
for e.g. `#define HAVE_DECL_FOO 1`/`#define HAVE_DECL_FOO 0`, inconsistently 
and immutably. Meson allows `#define HAVE_FOO 1`/`#define HAVE_FOO 0`). This 
makes the `#if`-conditionals in code more consistent. `-Werror=undef` can be 
used to catch mistyped HAVE_ variables that often lurk for years without anyone 
noticing.

Finally, meson+ninja do a better job at expressing and managing dependencies. 
Meson is able to capture dependencies between build steps much better than 
autotools, and in effect ninja is great at *partial* rebuilds. So partial 
rebuilds that only depend on a single file become nearly instantaneous and 
operations like "change build flag and rebuild anything *using* that build 
flag" work. With autotools, in many cases a full rebuild-from-scratch operation 
would be necessary.

> rpm sits really early in the bootstrap chain

When *installing* a new system, having rpm depend on python would be an issue. 
But when bootstrapping in the sense of building from scratch, I don't think 
this is a significant issue. Python is generally available on all platforms, 
and a non-rpm-packaged or non-native-rpm-installed-version could be used to 
build rpm. After rpm has been built, it wouldn't care about Python any more. So 
requiring Python at some point in the bootstrap cycle seems totally OK.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625711545___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Igor Gnatenko
> Oh, I see I said "patches might be considered" in #887, which is wrong and 
> I'll need to correct that in the ticket too.

Wish I'd know this earlier :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625710990___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Igor Gnatenko
>  Rpm is a low-level tool needed early in bootstrapping of a distro, and 
> Python as a pre-requisite for building rpm is not acceptable.

Why so? Why do you need to start with RPM? In order to get something what you 
could call a system, you'd need to compile util-linux (to create filesystems, 
run `su` and such, and after all, use `kill` command which is used in 
rpmbuild), and that will require meson very soon.

If you are bootstrapping new system (which you most likely don't), you'll 
already have these tools available in your environment so you will simply 
cross-compile the whole thing. Probably would be helpful to describe how you 
imagine bootstrapping new systems and how often people actually do so?

Can you put more description about "bootstrapping issues"?

> Besides the tests, and the fact that autotools is the devil I know and 
> prefer, rpm sits really early in the bootstrap chain, and adding significant 
> extra burden there is not acceptable. If glibc or gcc adopt some 
> non-autotools based build-system, I'm willing to reconsider.

I know and very much appreciate that you are basically the one writing most of 
the code in RPM, but does it mean that it should stay like this? I mean that it 
would be same as if you have said "I'm not going to accept patch which 
implements support for ed25519 signatures because I prefer rsa".

The other thing is the test suite - it is slow, horrible and only few people 
can basically write those. I am pretty sure you wish to get more tests, but it 
is not happening also because autotest is just :hankey: . At least I personally 
wanted to cover dependencies and signatures stuff with tests, but just gave up.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625710802___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Panu Matilainen
Oh, I see I said "patches might be considered" in #887, which is wrong and I'll 
need to correct that in the ticket too.

Besides the tests, and the fact that autotools is the devil I know and prefer, 
rpm sits really early in the bootstrap chain, and adding significant extra 
burden there is not acceptable. If glibc or gcc adopt some non-autotools based 
build-system, I'm willing to reconsider.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625702675___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Panu Matilainen
Igor, don't waste your time. Our ours. Please.

We're not going to change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625699184___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Igor Gnatenko
@mlschroe well, don't worry - I will convert all the test :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625697384___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Michael Schroeder
See also issue #887. The hard part is not the build process, but converting all 
the tests.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625694952___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Igor Gnatenko
@ignatenkobrain pushed 1 commit.

45c863b2f064df76bc4a23185be76c0c239a2eef  Add meson buildsystem


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209/files/85df61d8e2fcc174b4b9dbeed2f513ce884a25fc..45c863b2f064df76bc4a23185be76c0c239a2eef
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Igor Gnatenko
@ignatenkobrain pushed 1 commit.

85df61d8e2fcc174b4b9dbeed2f513ce884a25fc  Add meson buildsystem


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209/files/78563442c2060aa3a265f16c12b875e015604d61..85df61d8e2fcc174b4b9dbeed2f513ce884a25fc
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Panu Matilainen
I wish you'd asked before starting such a big work. 
Rpm is a low-level tool needed early in bootstrapping of a distro, and Python 
as a pre-requisite for building rpm is not acceptable. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625647095___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-07 Thread Igor Gnatenko
@ignatenkobrain pushed 1 commit.

56082ae5a49d0eac581cac4c2f49a08069a2fc63  Add meson buildsystem


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209/files/b7f9f18c32600e32e3117139cdd61b2f90ff7269..56082ae5a49d0eac581cac4c2f49a08069a2fc63
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint