Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote: > Or uber minimal, can't get much smaller still 5.20s > https://travis-ci.org/Obsidian-StudiosInc/asspr#L165 > https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac Consider AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman]) foreign

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote: > Or uber minimal, can't get much smaller still 5.20s > https://travis-ci.org/Obsidian-StudiosInc/asspr#L165 > https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac That takes 2.0s here, on quite old hardware, though with primed cache. >

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread William L. Thomson Jr.
On Sat, 25 Nov 2017 00:20:38 + Peter Stuge wrote: > William L. Thomson Jr. wrote: > > I cannot understand why systems get faster, yet configure seems to > > take the same amount of time and is super slow. > > The generated configure scripts can be fork intensive, which is

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote: > I cannot understand why systems get faster, yet configure seems to > take the same amount of time and is super slow. The generated configure scripts can be fork intensive, which is still fairly expensive. But I think the problem is more with poorly written

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread William L. Thomson Jr.
On Thu, 23 Nov 2017 16:36:07 + Peter Stuge wrote: > > It's arguably a bug that a projects gets huge. Sometimes huge projects are split into many internally. Imagine this was using autotools. I doubt it could use a master configure for all sub projects, but maybe.

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-23 Thread Peter Stuge
Martin Vaeth wrote: > > 1. Doing a full clean build [..] the speed of make or ninja is hugely > > offset by the compilation speed, and their overhead is negligible. > > It depends on the definition of negligible. For huge projects like > boost or chromium it is several minutes It's arguably a

[gentoo-dev] Re: cmake + ninja vs autotools

2017-11-22 Thread Martin Vaeth
Georg Rudoy <0xd34df...@gmail.com> wrote: > 1. Doing a full clean build [..] > the speed of make or ninja is hugely offset by the compilation speed, > and their overhead is negligible. It depends on the definition of negligible. For huge projects like boost or chromium it is several minutes:

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-19 Thread Michael Orlitzky
On 11/19/2017 01:00 PM, William L. Thomson Jr. wrote: >> >> This is broken: Static metadata like DEPEND must not depend >> on dynamic data like environment variables which are supposed >> to change at emerge time. > > I wondered about that. I guess adding to DEPEND via eclass is bad then. > So

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-19 Thread Georg Rudoy
On 19.11.17 at 16:49 user Martin Vaeth wrote: >> Ninja is most of the speed of meson less configure time savings > > ++ > For eix, the main motivation to support meson as an > alternative build system was to be able to use ninja... As somebody having a big C++/Qt/cmake project:

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-19 Thread William L. Thomson Jr.
On Sun, 19 Nov 2017 16:49:51 + (UTC) Martin Vaeth wrote: > William L. Thomson Jr. wrote: > > > > case ${CMAKE_MAKEFILE_GENERATOR} in > > emake) > > DEPEND="sys-devel/make" > > ;; > > ninja) > >

[gentoo-dev] Re: cmake + ninja vs autotools

2017-11-19 Thread Martin Vaeth
William L. Thomson Jr. wrote: > > case ${CMAKE_MAKEFILE_GENERATOR} in > emake) > DEPEND="sys-devel/make" > ;; > ninja) > DEPEND="dev-util/ninja" > ;; This is broken: Static metadata like DEPEND

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-17 Thread William L. Thomson Jr.
On Sat, 18 Nov 2017 02:52:33 +0100 Francesco Riosa wrote: > > In my user opinion this has no place in a ebuild unless upstream > clearly say to use (or evidently use) ninja as it main generator. I think Gentoo deviates from upstreams fairly considerably at times. I see this as

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-17 Thread Francesco Riosa
On 18/11/2017 00:35, Michael Palimaka wrote: > On 11/16/2017 02:27 PM, William L. Thomson Jr. wrote: >> It maybe worth considering switching the default generator in the >> cmake-utils.eclass from the default of emake to ninja. >> >> - : ${CMAKE_MAKEFILE_GENERATOR:=emake} >> + :

[gentoo-dev] Re: cmake + ninja vs autotools

2017-11-17 Thread Michael Palimaka
On 11/16/2017 02:27 PM, William L. Thomson Jr. wrote: > It maybe worth considering switching the default generator in the > cmake-utils.eclass from the default of emake to ninja. > > - : ${CMAKE_MAKEFILE_GENERATOR:=emake} > + : ${CMAKE_MAKEFILE_GENERATOR:=ninja} > > For those with cmake ebuilds