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
signature.asc
Description: Digital signature
