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
> 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
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
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
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
> 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
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
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
> > * 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
> @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)
>
>
@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,
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
> 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
@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
@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
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
(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:
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:
> 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
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
> 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:
> 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,
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
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:
@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:
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:
@ignatenkobrain pushed 1 commit.
45c863b2f064df76bc4a23185be76c0c239a2eef Add meson buildsystem
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ignatenkobrain pushed 1 commit.
85df61d8e2fcc174b4b9dbeed2f513ce884a25fc Add meson buildsystem
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
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
@ignatenkobrain pushed 1 commit.
56082ae5a49d0eac581cac4c2f49a08069a2fc63 Add meson buildsystem
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
30 matches
Mail list logo
