Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Tuesday, February 7, 2017 9:23:22 AM EST William Hubbs wrote: > On Tue, Feb 07, 2017 at 01:22:22AM +0100, Maciej Mrozowski wrote: > > I'd recommend to jump a bandwagon and switch to CMake. > > > > Yes, it's ugly in certain areas, has its quirks but whoever switches to it > > ones, never goes back, and not because of technical debt being too big. > > > > Also because I can help with it (and a lot of folks can), while Meson is > > still largely unknown. > > Thanks for the offer, but i have no interest in CMake. I have heard from > multiple sources how difficult it is to work with. I did not find CMake difficult to work with at all. I use it for jem[1], a port of java-config to C. Though my main reason for CMake vs Autotools was in things like ability to make a rpm, deb, and tarball easily. Things I did not need to do on Gentoo with an ebuild. Yes that can be done in Autotools, just I found it easier to do via CMake. Now CMake does have dependencies, and for that reason I would avoid for openrc. The less dependencies the better. Eventually I may move jem back to Autotools for the same reason. I do use Autotools for asspr[2]. CMake would be overkill for asspr. I would experiment with CMake yourself and form your own opinion. I really do not think it is difficult. I have not heard anyone say it was difficult. Just the opposite. 1. https://github.com/Obsidian-StudiosInc/jem 2. https://github.com/Obsidian-StudiosInc/asspr -- William L. Thomson Jr. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Tue, Feb 07, 2017 at 01:22:22AM +0100, Maciej Mrozowski wrote: > I'd recommend to jump a bandwagon and switch to CMake. > > Yes, it's ugly in certain areas, has its quirks but whoever switches to it > ones, never goes back, and not because of technical debt being too big. > > Also because I can help with it (and a lot of folks can), while Meson is > still > largely unknown. Thanks for the offer, but i have no interest in CMake. I have heard from multiple sources how difficult it is to work with. The current plan for this, in the upstream issue, is to offer a meson build and keep the makefiles around for a while. I will ask all downstream distros to take a look at the meson build and let me know if there are issues that would block them from using it. On Gentoo, I know of at least these: - Meson needs a new release (0.38.1 should be coming soon) -- actually this affects any distro. - meson itself needs to be keyworded on all of our arches. - ninja needs to be fixed so that it works on amd64 hardened. So, it will be some time before any major changes, like dropping the Makefiles, happen. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On poniedziałek, 30 stycznia 2017 14:04:06 CET William Hubbs wrote: > All, > > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? I'd recommend to jump a bandwagon and switch to CMake. Yes, it's ugly in certain areas, has its quirks but whoever switches to it ones, never goes back, and not because of technical debt being too big. Also because I can help with it (and a lot of folks can), while Meson is still largely unknown. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
2017-02-03 10:52 GMT+01:00 Lars Wendler : > On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote: > > >On 02/03/2017 10:10 AM, Benda Xu wrote: > >> William Hubbs writes: > >> > >>> I have been looking at the meson build system [1] [2], and I like > >>> what I see. > >>> > >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to > >>> the meson build system [3]. > >>> > >>> As I said on the bug, the downside is the addition of py3 and ninja > >>> as build time dependencies, but I think the upside (a build system > >>> where we don't have to worry about parallel make issues or > >>> portability) outweighs that. > >>> > >>> What do folks think here? > >> > >> I would discourage it. Making OpenRC build-depend on python > >> introduces unnecessary complexity that will undermine the > >> portability of OpenRC sooner or later. > >> > >> After all OpenRC is a small program easy to build with a hand-written > >> Makefile. > >> > >> Parallel make issues? No problem let's just solve it. > >> > >> > >> Please, keep it simple. > > > >I'm adding my support to this sentiment > > > > > > +1 > > -- > Lars Wendler > Gentoo package maintainer > GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 > > Attention! New gpg key! See > https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html > Replay @ random using gmail webmail interface; May be worth mentioning that also other distro like Alpine Linux uses openrc, they can be interested
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote: >On 02/03/2017 10:10 AM, Benda Xu wrote: >> William Hubbs writes: >> >>> I have been looking at the meson build system [1] [2], and I like >>> what I see. >>> >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to >>> the meson build system [3]. >>> >>> As I said on the bug, the downside is the addition of py3 and ninja >>> as build time dependencies, but I think the upside (a build system >>> where we don't have to worry about parallel make issues or >>> portability) outweighs that. >>> >>> What do folks think here? >> >> I would discourage it. Making OpenRC build-depend on python >> introduces unnecessary complexity that will undermine the >> portability of OpenRC sooner or later. >> >> After all OpenRC is a small program easy to build with a hand-written >> Makefile. >> >> Parallel make issues? No problem let's just solve it. >> >> >> Please, keep it simple. > >I'm adding my support to this sentiment > > +1 -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpEkZOYA01EV.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 02/03/2017 10:10 AM, Benda Xu wrote: > William Hubbs writes: > >> I have been looking at the meson build system [1] [2], and I like what I >> see. >> >> I have opened an issue on OpenRC's github wrt migrating OpenRC to the >> meson build system [3]. >> >> As I said on the bug, the downside is the addition of py3 and ninja as >> build time dependencies, but I think the upside (a build system where >> we don't have to worry about parallel make issues or portability) >> outweighs that. >> >> What do folks think here? > > I would discourage it. Making OpenRC build-depend on python introduces > unnecessary complexity that will undermine the portability of OpenRC > sooner or later. > > After all OpenRC is a small program easy to build with a hand-written > Makefile. > > Parallel make issues? No problem let's just solve it. > > > Please, keep it simple. I'm adding my support to this sentiment -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
William Hubbs writes: > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? I would discourage it. Making OpenRC build-depend on python introduces unnecessary complexity that will undermine the portability of OpenRC sooner or later. After all OpenRC is a small program easy to build with a hand-written Makefile. Parallel make issues? No problem let's just solve it. Please, keep it simple. Benda signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 02/01/2017 10:46 AM, William Hubbs wrote: > On Wed, Feb 01, 2017 at 03:55:17PM +, James Le Cuirot wrote: >> On Wed, 1 Feb 2017 09:39:34 -0600 >> William Hubbs wrote: >> >>> I thought about autotools. I'm not really fond of its syntax, and I've >>> been told that, to use autotools correctly, I would need to start >>> generating manual release tarballs again because I would need to put >>> the autotools generated cruft in them. >> >> Not all that hard, to be honest. Autotools adds a "make dist" target and >> then you just upload that tarball to GitHub by adding a new release. > > Is that functionality available through the github API, or do you have > to go to the web site? > > Also, another concern I would have is the tarballs are not reproducible > that way. > > William > Well, you could check in the generated files, if you're worried about reproducible builds. E.g., Wine does that: https://source.winehq.org/git/wine.git/blob/HEAD:/configure The build files change pretty rarely, and it saves end users the trouble of needing to have autoconf/automake, while also providing reproducible tarballs. I think that strongly outweighs the "they're unnecessary / easily generated" argument. Back to the original question, I'm of the opinion that the build system should be something well tested, not some fad project. Autotools/Cmake would both fit the bill here. I'm not deeply involved with OpenRC though, so it's really up to you. At the end of the day though, if you're just researching if it's viable and not actually implementing it, then you don't really need to see if other people are okay with it. Make a separate git branch from master and go nuts. -- -Austin Austin English Gentoo Developer GPG: 00B3 2957 B94B F3E1 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 02/01/2017 08:53 AM, Ian Stakenvicius wrote: > On 01/02/17 09:43 AM, William Hubbs wrote: >> On Wed, Feb 01, 2017 at 01:18:42PM +0100, Michał Górny wrote: >>> W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs >>> napisał: All, I have been looking at the meson build system [1] [2], and I like what I see. I have opened an issue on OpenRC's github wrt migrating OpenRC to the meson build system [3]. As I said on the bug, the downside is the addition of py3 and ninja as build time dependencies, but I think the upside (a build system where we don't have to worry about parallel make issues or portability) outweighs that. What do folks think here? >>> >>> On behalf of systemd team, I would like to officially contradict any >>> rumors that those ideas are in any way caused by systemd team. OpenRC >>> developers are shooting their own feet of their own choice. >> >> I don't even know what this is about. I have said nothing about systemd >> or any other package like that. >> > > Pre-emptive strike is all. We all know systemd gets blamed for > everything. :D My bathtub drains too fast, making it hard to take a bath instead of a shower. Freaking systemd.. ;) -- -Austin Austin English Gentoo Developer GPG: 00B3 2957 B94B F3E1 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, Feb 01, 2017 at 12:25:37PM -0500, james wrote: > On 02/01/2017 10:40 AM, William Hubbs wrote: > > On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote: > >> On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote: > >>> As I said on the bug, the downside is the addition of py3 and ninja as > >>> build time dependencies, but I think the upside (a build system where > >>> we don't have to worry about parallel make issues or portability) > >>> outweighs that. > >> Could you please link or otherwise explain the portability issue? > > > > I'm not talking about a specific instance, just the flexability you get > > with a build system. You let it handle the details of building > > executables, linking libraries, etc. > > > > I have heard from more than one person that the OpenRC makefiles are > > not written well, and I agree, so I've been looking for a build system > > for a while. > > > > I thought about autotools. I'm not really fond of its syntax, and I've > > been told that, to use autotools correctly, I would need to start > > generating manual release tarballs again because I would need to put the > > autotools generated cruft in them. > > > > I'm open to suggestions. I picked meson to experiment with because it > > has a very nice clean syntax. > > > > William > > > > 'TUP' is the fastest build system of the all? I believe many build > systems leverage or imitate what TUP does. I've read that for hand > crafting a specific build system, TUP is the most fundamental of the > building blocks. Here are a few links, there are many for your perusal:: > > > http://gittup.org/tup/make_vs_tup.html > > https://news.ycombinator.com/item?id=12622097 > > > I think TUP would really shine in a build system for embedded and > otherwise constrained build environments (limited resources) but > I have not vetted that theory out, as I usually lean on others > with greater depth of understanding in such matters. Still, from what I > read, TUP warrants monitoring as new code contributions keep moving this > blazingly fast build system tool forward. I took a brief look at this earlier. It appears to be a make replacement. In otherwords, it would be a back end that cmake or meson could leverage by writing tupfiles. cmake or meson are replacements for autotools (autoconf/automake/libtool). All of these (autotools, cmake, meson, etc) generate makefiles that are run by another tool to actually do the build. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, Feb 01, 2017 at 09:03:49AM -0600, William Hubbs wrote: > On Wed, Feb 01, 2017 at 11:54:41AM +0100, Tobias Klausmann wrote: > > Hi! > > > > On Mon, 30 Jan 2017, William Hubbs wrote: > > > I have been looking at the meson build system [1] [2], and I like what I > > > see. > > > > > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > > > meson build system [3]. > > > > > > As I said on the bug, the downside is the addition of py3 and ninja as > > > build time dependencies, but I think the upside (a build system where > > > we don't have to worry about parallel make issues or portability) > > > outweighs that. > > > > > > What do folks think here? > > > > Meson isn't even keyworded anywhere but amd64 and x86 and I > > couldn't find an indication that they care about off-mainstream > > architectures at all. Yes, it's written in Python as such is more > > portable than if it were written in C or somesuch, but for a > > build system, the arch it runs on and targets are more important > > than for most other programs. > > You are right that meson isn't keyworded anywhere but amd64 and x86, > and I will ask them about this because If they didn't want to support > off-mainstream arches this would be a blocker. Not just for OpenRC, but > for all consumers that convert to it. I checked with meson upstream, and they pointed me to Debian. Debian already has packages that use Meson on all arches such as https://packages.debian.org/sid/pitivi. It looks like it would just be a matter of keywording meson as other projects need it. Again, the makefiles can't go anywhere at this point. this is an upstream experiment to see how well meson would work. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 01/02/17 10:39 AM, William Hubbs wrote: > > I thought about autotools. I'm not really fond of its syntax, and I've > been told that, to use autotools correctly, I would need to start > generating manual release tarballs again because I would need to put the > autotools generated cruft in them. Well, #1, you should do that anyways. But, #2, no you don't -need- to have autoconf already run inside the tarball if you really don't want to; it's convention but there are projects that don't. Also, #3, doing this is as easy as running 'make dist' when you have an autotools build system, so generating said tarballs for release may actually be -easier- than what you're doing now. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 02/01/2017 10:39 AM, William Hubbs wrote: On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote: On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote: As I said on the bug, the downside is the addition of py3 and ninja as build time dependencies, but I think the upside (a build system where we don't have to worry about parallel make issues or portability) outweighs that. Could you please link or otherwise explain the portability issue? I'm not talking about a specific instance, just the flexability you get with a build system. You let it handle the details of building executables, linking libraries, etc. I have heard from more than one person that the OpenRC makefiles are not written well, and I agree, so I've been looking for a build system for a while. I thought about autotools. I'm not really fond of its syntax, and I've been told that, to use autotools correctly, I would need to start generating manual release tarballs again because I would need to put the autotools generated cruft in them. I'm open to suggestions. I picked meson to experiment with because it has a very nice clean syntax. William 'TUP' is the fastest build system of the all? I believe many build systems leverage or imitate what TUP does. I've read that for hand crafting a specific build system, TUP is the most fundamental of the building blocks. Here are a few links, there are many for your perusal:: http://gittup.org/tup/make_vs_tup.html https://news.ycombinator.com/item?id=12622097 I think TUP would really shine in a build system for embedded and otherwise constrained build environments (limited resources) but I have not vetted that theory out, as I usually lean on others with greater depth of understanding in such matters. Still, from what I read, TUP warrants monitoring as new code contributions keep moving this blazingly fast build system tool forward. If others have first hand experience with TUP, I'd very much like to read about their comments and experiences with TUP. hth, James
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 02/01/2017 10:40 AM, William Hubbs wrote: On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote: On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote: As I said on the bug, the downside is the addition of py3 and ninja as build time dependencies, but I think the upside (a build system where we don't have to worry about parallel make issues or portability) outweighs that. Could you please link or otherwise explain the portability issue? I'm not talking about a specific instance, just the flexability you get with a build system. You let it handle the details of building executables, linking libraries, etc. I have heard from more than one person that the OpenRC makefiles are not written well, and I agree, so I've been looking for a build system for a while. I thought about autotools. I'm not really fond of its syntax, and I've been told that, to use autotools correctly, I would need to start generating manual release tarballs again because I would need to put the autotools generated cruft in them. I'm open to suggestions. I picked meson to experiment with because it has a very nice clean syntax. William 'TUP' is the fastest build system of the all? I believe many build systems leverage or imitate what TUP does. I've read that for hand crafting a specific build system, TUP is the most fundamental of the building blocks. Here are a few links, there are many for your perusal:: http://gittup.org/tup/make_vs_tup.html https://news.ycombinator.com/item?id=12622097 I think TUP would really shine in a build system for embedded and otherwise constrained build environments (limited resources) but I have not vetted that theory out, as I usually lean on others with greater depth of understanding in such matters. Still, from what I read, TUP warrants monitoring as new code contributions keep moving this blazingly fast build system tool forward. hth, James
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Mon, Jan 30, 2017 at 03:08:42PM -0600, Dustin C. Hatch wrote: > On 2017-01-30 14:04, William Hubbs wrote: > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > > meson build system [3]. > > > > … > > > > What do folks think here? > > > > I looked at Meson a bit, and I liked almost everything, except the > configuration file-based mechanism for cross-compiling. Has anyone > thought about how that will integrate with Portage, or more > specifically, with cross-emerge/emerge-wrapper, and the environment > variable-based mechanism used by other build systems? I've never done any cross-compiling, but this is something that would need to be looked at before I could make this live in Gentoo if that happens. There is also an open bug for an eclass for the meson build system which I have been thinking about. Keep in mind folks that this thread was started along with the upstream issue to gather ideas. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, 1 Feb 2017 10:46:12 -0600 William Hubbs wrote: > On Wed, Feb 01, 2017 at 03:55:17PM +, James Le Cuirot wrote: > > On Wed, 1 Feb 2017 09:39:34 -0600 > > William Hubbs wrote: > > > > > I thought about autotools. I'm not really fond of its syntax, and > > > I've been told that, to use autotools correctly, I would need to > > > start generating manual release tarballs again because I would > > > need to put the autotools generated cruft in them. > > > > Not all that hard, to be honest. Autotools adds a "make dist" > > target and then you just upload that tarball to GitHub by adding a > > new release. > > Is that functionality available through the github API, or do you have > to go to the web site? The API has it covered. https://developer.github.com/v3/repos/releases/#create-a-release https://developer.github.com/v3/repos/releases/#upload-a-release-asset > Also, another concern I would have is the tarballs are not > reproducible that way. True though I see it has been discussed not all that long ago. There may even be a solution somewhere but I didn't find one in a hurry. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, Feb 01, 2017 at 03:55:17PM +, James Le Cuirot wrote: > On Wed, 1 Feb 2017 09:39:34 -0600 > William Hubbs wrote: > > > I thought about autotools. I'm not really fond of its syntax, and I've > > been told that, to use autotools correctly, I would need to start > > generating manual release tarballs again because I would need to put > > the autotools generated cruft in them. > > Not all that hard, to be honest. Autotools adds a "make dist" target and > then you just upload that tarball to GitHub by adding a new release. Is that functionality available through the github API, or do you have to go to the web site? Also, another concern I would have is the tarballs are not reproducible that way. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, 1 Feb 2017 09:39:34 -0600 William Hubbs wrote: > I thought about autotools. I'm not really fond of its syntax, and I've > been told that, to use autotools correctly, I would need to start > generating manual release tarballs again because I would need to put > the autotools generated cruft in them. Not all that hard, to be honest. Autotools adds a "make dist" target and then you just upload that tarball to GitHub by adding a new release. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote: > On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote: > > As I said on the bug, the downside is the addition of py3 and ninja as > > build time dependencies, but I think the upside (a build system where > > we don't have to worry about parallel make issues or portability) > > outweighs that. > Could you please link or otherwise explain the portability issue? I'm not talking about a specific instance, just the flexability you get with a build system. You let it handle the details of building executables, linking libraries, etc. I have heard from more than one person that the OpenRC makefiles are not written well, and I agree, so I've been looking for a build system for a while. I thought about autotools. I'm not really fond of its syntax, and I've been told that, to use autotools correctly, I would need to start generating manual release tarballs again because I would need to put the autotools generated cruft in them. I'm open to suggestions. I picked meson to experiment with because it has a very nice clean syntax. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, Feb 01, 2017 at 11:54:41AM +0100, Tobias Klausmann wrote: > Hi! > > On Mon, 30 Jan 2017, William Hubbs wrote: > > I have been looking at the meson build system [1] [2], and I like what I > > see. > > > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > > meson build system [3]. > > > > As I said on the bug, the downside is the addition of py3 and ninja as > > build time dependencies, but I think the upside (a build system where > > we don't have to worry about parallel make issues or portability) > > outweighs that. > > > > What do folks think here? > > Meson isn't even keyworded anywhere but amd64 and x86 and I > couldn't find an indication that they care about off-mainstream > architectures at all. Yes, it's written in Python as such is more > portable than if it were written in C or somesuch, but for a > build system, the arch it runs on and targets are more important > than for most other programs. You are right that meson isn't keyworded anywhere but amd64 and x86, and I will ask them about this because If they didn't want to support off-mainstream arches this would be a blocker. Not just for OpenRC, but for all consumers that convert to it. As I said on the upstream bug, this would be a long-term project if it goes through. The other blockers would be ninja and the cross build issue pointed out earlier at least. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 01/02/17 09:43 AM, William Hubbs wrote: > On Wed, Feb 01, 2017 at 01:18:42PM +0100, Michał Górny wrote: >> W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs >> napisał: >>> All, >>> >>> I have been looking at the meson build system [1] [2], and I like >>> what I >>> see. >>> >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to the >>> meson build system [3]. >>> >>> As I said on the bug, the downside is the addition of py3 and ninja >>> as >>> build time dependencies, but I think the upside (a build system where >>> we don't have to worry about parallel make issues or portability) >>> outweighs that. >>> >>> What do folks think here? >> >> On behalf of systemd team, I would like to officially contradict any >> rumors that those ideas are in any way caused by systemd team. OpenRC >> developers are shooting their own feet of their own choice. > > I don't even know what this is about. I have said nothing about systemd > or any other package like that. > Pre-emptive strike is all. We all know systemd gets blamed for everything. :D signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Wed, Feb 01, 2017 at 01:18:42PM +0100, Michał Górny wrote: > W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs > napisał: > > All, > > > > I have been looking at the meson build system [1] [2], and I like > > what I > > see. > > > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > > meson build system [3]. > > > > As I said on the bug, the downside is the addition of py3 and ninja > > as > > build time dependencies, but I think the upside (a build system where > > we don't have to worry about parallel make issues or portability) > > outweighs that. > > > > What do folks think here? > > On behalf of systemd team, I would like to officially contradict any > rumors that those ideas are in any way caused by systemd team. OpenRC > developers are shooting their own feet of their own choice. I don't even know what this is about. I have said nothing about systemd or any other package like that. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs napisał: > All, > > I have been looking at the meson build system [1] [2], and I like > what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja > as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? On behalf of systemd team, I would like to officially contradict any rumors that those ideas are in any way caused by systemd team. OpenRC developers are shooting their own feet of their own choice. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
Hi! On Mon, 30 Jan 2017, William Hubbs wrote: > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? Meson isn't even keyworded anywhere but amd64 and x86 and I couldn't find an indication that they care about off-mainstream architectures at all. Yes, it's written in Python as such is more portable than if it were written in C or somesuch, but for a build system, the arch it runs on and targets are more important than for most other programs. As others have pointed out, the gains are not quite as obvious as the potential downsides are. Just my 2 Rappen, Tobias -- Sent from aboard the Culture ship GSV Just the Washing Instruction Chip in Life's Rich Tapestry
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Tue, Jan 31, 2017 at 9:29 PM, Kent Fredric wrote: > > And we should be keeping the @system essentials set required for new > installations > to be as minimal as possible without losing functionality. > Keep in mind that it is pretty safe to put openrc in package.provided, well, as long as you create one symlink for all the broken packages that still reference the wrong path for functions.sh. /me ducks -- Rich
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Mon, 30 Jan 2017 14:04:06 -0600 William Hubbs wrote: > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. On principle I would discourage this course of action. Critical infrastructure should be built on proven and established technology that has practically become boring to the point of almost-stagnation. Building things atop of newer technology ends up being like building upon shifting sands. And all this is doubly important if you're ever needing to bootstrap. ie: It might be justifiable to build openrc on top of meson on an established system which already has a working openrc, but building openrc on meson when you're installing your first Gentoo install is going to be much more painful than it should be. And we should be keeping the @system essentials set required for new installations to be as minimal as possible without losing functionality. And here, I think the objectives of being parallel-make friendly are small in compare with the overhead for ensuring the dependencies are present and working and usable on a clean install. But a package that has only been in tree a measly 7 months seems far, far too premature to switch to being a mandatory part of the critical path. pgpWmHATLEQhC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote: > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. Could you please link or otherwise explain the portability issue? -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Mon, Jan 30, 2017 at 12:04 PM, William Hubbs wrote: > All, > > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? This seems like a bad idea, for most of the reasons given by @skarnet. The additional build-time dependencies are bad for such a small and core project. And for what? Faster build times? OpenRC builds in less than 4 seconds on my system. You claimed parallel make check is broken, citing [1], but that actually occurs with -j1 as well, making me question whether you've investigated the bug at all. Cart before the horse... [1] https://bugs.gentoo.org/show_bug.cgi?id=374191
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 01/30/2017 15:04, William Hubbs wrote: > All, > > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? > > Thanks, > > William > > [1] https://mesonbuild.com > [2] https://www.youtube.com/watch?v=ae9_rNuFaQM > [3] https://github.com/OpenRC/openrc/issues/116 dev-util/ninja is hosed at the moment on a hardened/amd64 system built using gcc-6.x. See Bug #604198. This one package is holding up my dev box from updating clang/llvm and several other dependent packages. I've given up trying to debug it, too. It's something gcc-6.x is doing, code-generation-wise, that is beyond my ability to troubleshoot. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 2017-01-30 14:04, William Hubbs wrote: > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > … > > What do folks think here? > I looked at Meson a bit, and I liked almost everything, except the configuration file-based mechanism for cross-compiling. Has anyone thought about how that will integrate with Portage, or more specifically, with cross-emerge/emerge-wrapper, and the environment variable-based mechanism used by other build systems? -- ♫Dustin
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Mon, 30 Jan 2017 14:04:06 -0600 William Hubbs wrote: > I have been looking at the meson build system [1] [2], and I like what I > see. I've still only read the documentation but I agree with your assessment. It's nice to hear something positive about a build system for once. > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. I don't see those as a problem. I suspect it's only a matter of time before something else in @system pulls those in. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpwu2UuIiHLC.pgp Description: OpenPGP digital signature
[gentoo-dev] rfc: moving OpenRC to a meson-based build
All, I have been looking at the meson build system [1] [2], and I like what I see. I have opened an issue on OpenRC's github wrt migrating OpenRC to the meson build system [3]. As I said on the bug, the downside is the addition of py3 and ninja as build time dependencies, but I think the upside (a build system where we don't have to worry about parallel make issues or portability) outweighs that. What do folks think here? Thanks, William [1] https://mesonbuild.com [2] https://www.youtube.com/watch?v=ae9_rNuFaQM [3] https://github.com/OpenRC/openrc/issues/116 signature.asc Description: Digital signature