Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-07 Thread William L. Thomson Jr.
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

2017-02-07 Thread William Hubbs
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

2017-02-06 Thread Maciej Mrozowski
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 Thread Francesco Riosa
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

2017-02-03 Thread 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


pgpEkZOYA01EV.pgp
Description: Digitale Signatur von OpenPGP


Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 Thread Kristian Fiskerstrand
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

2017-02-03 Thread Benda Xu
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

2017-02-02 Thread Austin English


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

2017-02-02 Thread Austin English
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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread Ian Stakenvicius
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

2017-02-01 Thread james

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

2017-02-01 Thread james

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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread James Le Cuirot
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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread James Le Cuirot
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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread Ian Stakenvicius
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

2017-02-01 Thread William Hubbs
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

2017-02-01 Thread Michał Górny
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

2017-02-01 Thread Tobias Klausmann
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

2017-02-01 Thread Rich Freeman
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

2017-01-31 Thread Kent Fredric
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

2017-01-31 Thread Robin H. Johnson
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

2017-01-31 Thread Matt Turner
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

2017-01-31 Thread Joshua Kinard
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

2017-01-30 Thread Dustin C. Hatch
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

2017-01-30 Thread James Le Cuirot
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

2017-01-30 Thread William Hubbs
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