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

[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 +0000, 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