Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-dev] cmake + ninja vs autotools
294 views
Skip to first unread message
William L. Thomson Jr.
Nov 15, 2017, 10:30:02 PM11/15/17
to
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 you can test this out now via
CMAKE_MAKEFILE_GENERATOR="ninja"
inherit cmake-utils
Working with both cmake and meson. It seems the real performance of
meson comes from ninja. I am a bit more a fan of cmake than meson for
cpack, generation of deb, rpm, and binary tarball, in addition to
sources. That can be done with meson but not as elegantly at this time.
ninja is noticeably faster than make. I haven't seen any cases yet where
cmake autotools works, and ninja does not. They seem pretty equal, so
should be safe. Of course could use testing first.
Again something to consider. Myself I am avoiding autotools anywhere I
can, mostly because of the slow configure and also slow make. Anytime I
use cmake, I am using ninja generator.
--
William L. Thomson Jr.
cmake-utils.eclass from the default of emake to ninja.
- : ${CMAKE_MAKEFILE_GENERATOR:=emake}
+ : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
For those with cmake ebuilds you can test this out now via
CMAKE_MAKEFILE_GENERATOR="ninja"
inherit cmake-utils
Working with both cmake and meson. It seems the real performance of
meson comes from ninja. I am a bit more a fan of cmake than meson for
cpack, generation of deb, rpm, and binary tarball, in addition to
sources. That can be done with meson but not as elegantly at this time.
ninja is noticeably faster than make. I haven't seen any cases yet where
cmake autotools works, and ninja does not. They seem pretty equal, so
should be safe. Of course could use testing first.
Again something to consider. Myself I am avoiding autotools anywhere I
can, mostly because of the slow configure and also slow make. Anytime I
use cmake, I am using ninja generator.
--
William L. Thomson Jr.
Brian Evans
Nov 16, 2017, 8:30:02 AM11/16/17
to
On 11/15/2017 10: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 you can test this out now via
>
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
>
> Working with both cmake and meson. It seems the real performance of
> meson comes from ninja. I am a bit more a fan of cmake than meson for
> cpack, generation of deb, rpm, and binary tarball, in addition to
> sources. That can be done with meson but not as elegantly at this time.
>
> ninja is noticeably faster than make. I haven't seen any cases yet where
> cmake autotools works, and ninja does not. They seem pretty equal, so
> should be safe. Of course could use testing first.
There are still cases where ninja fails...
> 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 you can test this out now via
>
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
>
> Working with both cmake and meson. It seems the real performance of
> meson comes from ninja. I am a bit more a fan of cmake than meson for
> cpack, generation of deb, rpm, and binary tarball, in addition to
> sources. That can be done with meson but not as elegantly at this time.
>
> ninja is noticeably faster than make. I haven't seen any cases yet where
> cmake autotools works, and ninja does not. They seem pretty equal, so
> should be safe. Of course could use testing first.
I have forcefully set emake in dev-db/{mysql,mysql-cluster} because they
fail to build with ninja (using the cmake generator) yet emake works
just fine.
Brian
Christoph Junghans
Nov 16, 2017, 8:50:02 AM11/16/17
to
On Nov 16, 2017 6:29 AM, "Brian Evans" <grkn...@gentoo.org> wrote:
On 11/15/2017 10:27 PM, William L. Thomson Jr. wrote:There are still cases where ninja fails...
> 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 you can test this out now via
>
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
>
> Working with both cmake and meson. It seems the real performance of
> meson comes from ninja. I am a bit more a fan of cmake than meson for
> cpack, generation of deb, rpm, and binary tarball, in addition to
> sources. That can be done with meson but not as elegantly at this time.
>
> ninja is noticeably faster than make. I haven't seen any cases yet where
> cmake autotools works, and ninja does not. They seem pretty equal, so
> should be safe. Of course could use testing first.
Ninja doesn't support Fortran as well.
Christoph Junghans
Nov 16, 2017, 11:20:02 AM11/16/17
to
2017-11-16 6:44 GMT-07:00 Christoph Junghans <jung...@gentoo.org>:
>
>
> On Nov 16, 2017 6:29 AM, "Brian Evans" <grkn...@gentoo.org> wrote:
>
> On 11/15/2017 10: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 you can test this out now via
>>
>> CMAKE_MAKEFILE_GENERATOR="ninja"
>> inherit cmake-utils
>>
>> Working with both cmake and meson. It seems the real performance of
>> meson comes from ninja. I am a bit more a fan of cmake than meson for
>> cpack, generation of deb, rpm, and binary tarball, in addition to
>> sources. That can be done with meson but not as elegantly at this time.
>>
>> ninja is noticeably faster than make. I haven't seen any cases yet where
>> cmake autotools works, and ninja does not. They seem pretty equal, so
>> should be safe. Of course could use testing first.
>
> There are still cases where ninja fails...
>
> Ninja doesn't support Fortran as well.
Besides not supporting the full feature set.
>
>
> On Nov 16, 2017 6:29 AM, "Brian Evans" <grkn...@gentoo.org> wrote:
>
> On 11/15/2017 10: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 you can test this out now via
>>
>> CMAKE_MAKEFILE_GENERATOR="ninja"
>> inherit cmake-utils
>>
>> Working with both cmake and meson. It seems the real performance of
>> meson comes from ninja. I am a bit more a fan of cmake than meson for
>> cpack, generation of deb, rpm, and binary tarball, in addition to
>> sources. That can be done with meson but not as elegantly at this time.
>>
>> ninja is noticeably faster than make. I haven't seen any cases yet where
>> cmake autotools works, and ninja does not. They seem pretty equal, so
>> should be safe. Of course could use testing first.
>
> There are still cases where ninja fails...
>
> Ninja doesn't support Fortran as well.
Ninja vs make didn't seem to make big time difference (for cmake at
least). Back in 2013 ago only found a 40sec difference (of an 6.5 min
overall build) when building kdelibs averaging over 3 builds, which
had more than 40s scatter in the individual builds.
That coincides with my own experience outside of portage where ninja
and make are pretty much even for a full build, but ninja is much
faster in figuring out which parts to rebuild in a partial build.
William L. Thomson Jr.
Nov 16, 2017, 11:50:02 AM11/16/17
to
On Thu, 16 Nov 2017 09:17:52 -0700
Christoph Junghans <jung...@gentoo.org> wrote:
>
> > Ninja doesn't support Fortran as well.
> Besides not supporting the full feature set.
That does not seem to be effecting meson. Which only supports ninja.
Christoph Junghans <jung...@gentoo.org> wrote:
>
> > Ninja doesn't support Fortran as well.
> Besides not supporting the full feature set.
A considerable amount of projects are switching to meson, look around.
I have switched over a couple projects I am working on. I have worked
with all three, autotools, cmake, and meson. I prefer cmake + ninja.
The performance of meson vs cmake is negligible. Given cmake cpack, I
prefer that for now over meson. I could not make a strong case for
speed of cmake vs meson. That is moot speed wise, pretty equal. Meson
maybe a tad faster.
> Ninja vs make didn't seem to make big time difference (for cmake at
> least). Back in 2013 ago only found a 40sec difference (of an 6.5 min
> overall build) when building kdelibs averaging over 3 builds, which
> had more than 40s scatter in the individual builds.
considerable time savings in the smaller projects I am working on,
ecrire, entrance, clipboard, and some others.
Enlightenment desktop for 0.23 release will have dropped autotools
entirely for meson. 0.22 already ships with meson. I switched over and
it builds faster. No problems there with ninja. I think EFL may switch
to meson as well. Other E projects like rage have already.
> That coincides with my own experience outside of portage where ninja
> and make are pretty much even for a full build, but ninja is much
> faster in figuring out which parts to rebuild in a partial build.
over some stuff in travis and show via CI the difference in time. I see
it all the time in development doing routine builds as part of code,
build, test, code, etc. Rinse and repeat.
Michael Palimaka
Nov 17, 2017, 6:40:02 PM11/17/17
to
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 you can test this out now via
>
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
If testing this, please use : ${CMAKE_MAKEFILE_GENERATOR:=ninja} in
> 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 you can test this out now via
>
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
ebuilds unless the emake generator is explicitly known not to work. This
will preserve user choice if they want to avoid ninja for some reason.
Francesco Riosa
Nov 17, 2017, 9:00:02 PM11/17/17
to
say to use (or evidently use) ninja as it main generator.
In cases where ninja is considered (by upstream) the best option,
Michael suggestion to make it overridable is a very wise one.
In that case, please also remember to depend on ninja
Since other emails (by Christoph and Brian) in this thread make evident
that it's not a drop in replacement, fixing it in the eclass seem a bad
idea, but that probably should be reconsidered when ninja become more
capable.
William L. Thomson Jr.
Nov 17, 2017, 9:10:02 PM11/17/17
to
On Sat, 18 Nov 2017 02:52:33 +0100
Francesco Riosa <viv...@gmail.com> 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
Francesco Riosa <viv...@gmail.com> 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.
see this as case where Gentoo can help facility things to upstream.
Maybe they haven't the time to test, etc.
Current example
https://sourceforge.net/p/firebird/mailman/firebird-devel/thread/assp.04935012e0.20171116111219.18e86899%40wlt.obsidian-studios.com/#msg36117925
> In cases where ninja is considered (by upstream) the best option,
> Michael suggestion to make it overridable is a very wise one.
> In that case, please also remember to depend on ninja
case ${CMAKE_MAKEFILE_GENERATOR} in
emake)
DEPEND="sys-devel/make"
;;
ninja)
DEPEND="dev-util/ninja"
;;
> Since other emails (by Christoph and Brian) in this thread make
> evident that it's not a drop in replacement, fixing it in the eclass
> seem a bad idea, but that probably should be reconsidered when ninja
> become more capable.
Maybe worth a bug to track stuff that builds fine and things that fail.
Could use the math alone to make a final call. More packages fail,
stick with make. if only a few, switch to ninja and have those stick
with the slow make.
Either way up to others. I am just passing on whats going on in many
other FOSS projects. Ninja is most of the speed of meson less configure
time savings.
Martin Vaeth
Nov 19, 2017, 12:00:02 PM11/19/17
to
William L. Thomson Jr. <wlt...@o-sinc.com> wrote:
>
> case ${CMAKE_MAKEFILE_GENERATOR} in
> emake)
> DEPEND="sys-devel/make"
> ;;
> ninja)
> DEPEND="dev-util/ninja"
> ;;
This is broken: Static metadata like DEPEND must not depend
>
> case ${CMAKE_MAKEFILE_GENERATOR} in
> emake)
> DEPEND="sys-devel/make"
> ;;
> ninja)
> DEPEND="dev-util/ninja"
> ;;
on dynamic data like environment variables which are supposed
to change at emerge time.
> Only 2 thus far does not sound like most things would have issues.
CMAKE_MAKEFILE_GENERATOR=ninja in my make.conf
since years, and the total list of packages which had
ever failed here (out of currently ~1500 installed)
is this:
dev-util/cmake
kde-apps/kate
kde-apps/gwenview
media-libs/avidemux-core
media-libs/avidemux-plugins
media-video/avidemux
media-video/kaffeine
media-video/kmplayer
net-vpn/kvpnc
sci-mathematics/reduce
This list might appear long, but note that
1. */avidemux* is essentially only 1 package
2. net-vpn/kvpnc is ancient and masked
3. sci-mathematics/reduce is ancient and masked
and moreover, perhaps some other entries of this list are even
obsolete (I do not have installed KDE 5, so I cannot try quickly;
when I had added the packages to the list, KDE 4 was rather new...)
> 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...
William L. Thomson Jr.
Nov 19, 2017, 1:10:02 PM11/19/17
to
On Sun, 19 Nov 2017 16:49:51 +0000 (UTC)
Martin Vaeth <mar...@mvath.de> wrote:
> William L. Thomson Jr. <wlt...@o-sinc.com> wrote:
> >
> > case ${CMAKE_MAKEFILE_GENERATOR} in
> > emake)
> > DEPEND="sys-devel/make"
> > ;;
> > ninja)
> > DEPEND="dev-util/ninja"
> > ;;
>
> 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.
Martin Vaeth <mar...@mvath.de> wrote:
> William L. Thomson Jr. <wlt...@o-sinc.com> wrote:
> >
> > case ${CMAKE_MAKEFILE_GENERATOR} in
> > emake)
> > DEPEND="sys-devel/make"
> > ;;
> > ninja)
> > DEPEND="dev-util/ninja"
> > ;;
>
> This is broken: Static metadata like DEPEND must not depend
> on dynamic data like environment variables which are supposed
> to change at emerge time.
> > Only 2 thus far does not sound like most things would have issues.
>
> In fact, almost nothing has issues.
>I am using
> CMAKE_MAKEFILE_GENERATOR=ninja in my make.conf
> since years, and the total list of packages which had
> ever failed here (out of currently ~1500 installed)
> is this:
>
> dev-util/cmake
> kde-apps/kate
> kde-apps/gwenview
> media-libs/avidemux-core
> media-libs/avidemux-plugins
> media-video/avidemux
> media-video/kaffeine
> media-video/kmplayer
> net-vpn/kvpnc
> sci-mathematics/reduce
>
> This list might appear long, but note that
considerably more have no issues with ninja than make.
Thanks for that information!
> > 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...
ninja. For all other stuff I prefer cmake + ninja. Kinda best of both
worlds. At least till meson can spit out deb and rpm, not just rpm spec.
I also like how cmake updates po files. Not sure about pot file, meson
does have something there, and can update them. Just a separate
process. cmake updates po all the time, I like that :)
But either way meson or cmake, ninja is the main speed for compiling.
Though I do like the cmake make output formatting and color, etc.
Georg Rudoy
Nov 19, 2017, 2:10:02 PM11/19/17
to
On 19.11.17 at 16:49 user Martin Vaeth <mar...@mvath.de> 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: there are basically two corner cases for the build scenario:
>> 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...
1. Doing a full clean build — that's what's relevant for Gentoo, and in this case the speed of make or ninja is hugely offset by the compilation speed, and their overhead is negligible.
2. Doing an incremental build after changing a couple of files — that's what relevant during normal development, and arguably not that relevant for Gentoo. And, ninja doesn't have that much of a speed advantage lately in this case. In fact, make turns out to be faster in the latter if the project is using automoc in cmake.
Just my two cents.
--
Georg Rudoy
Michael Orlitzky
Nov 19, 2017, 2:30:02 PM11/19/17
to
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 long as you add to DEPEND unconditionally, the issue that Martin
>>
>> 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.
>
pointed out does not apply. If you need to fudge the conditional, you
can put it behind a USE flag; for example,
DEPEND+=" some_use_expand_flag_foo? ( foo )"
in the eclass. That's still adding to DEPEND unconditionally, even
though its effect on the dependency tree (at "emerge" time) is
conditional on the USE flag.
Martin Vaeth
Nov 22, 2017, 5:20:02 AM11/22/17
to
Georg Rudoy <0xd34...@gmail.com> wrote:
> 1. Doing a full clean build [..]
boost or chromium it is several minutes: That's why these projects
switched to ninja. Admittedly, for eix the difference is probably
only a few seconds on most systems.
> 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
> and their overhead is negligible.
boost or chromium it is several minutes: That's why these projects
switched to ninja. Admittedly, for eix the difference is probably
only a few seconds on most systems.
Peter Stuge
Nov 23, 2017, 11:50:02 AM11/23/17
to
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 bug that a projects gets huge.
> > 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
The simplicity of configure+make is difficult to beat, but I also
agree that it's difficult or at least tedious to master autotools.
That is arguably reason enough to choose meson, but I think I will
stay with autotools for a while..
//Peter
William L. Thomson Jr.
Nov 24, 2017, 5:50:02 PM11/24/17
to
On Thu, 23 Nov 2017 16:36:07 +0000
Peter Stuge <pe...@stuge.se> wrote:
>
> It's arguably a bug that a projects gets huge.
Sometimes huge projects are split into many internally. Imagine this
Peter Stuge <pe...@stuge.se> wrote:
>
> It's arguably a bug that a projects gets huge.
was using autotools. I doubt it could use a master configure for all
sub projects, but maybe.
https://github.com/apache/incubator-netbeans
> The simplicity of configure+make is difficult to beat, but I also
> agree that it's difficult or at least tedious to master autotools.
gripe with what I call as a suite autotools. Make is not so much of an
issue, but configure I absolutely hate. I cannot understand why
systems get faster, yet configure seems to take the same amount of time
and is super slow.
On small projects configure can take longer than compile... Configure
is my main gripe against make/autotools. Plus all the other stuff,
auto-reconf, autogen, etc.
> That is arguably reason enough to choose meson, but I think I will
> stay with autotools for a while..
entirely as I like cmake+cpack. But I am surprised how many projects
are migrating to meson. Seems to be the current trend, and a
considerable amount moving to meson.
Meson vs cmake configure is not that big of a difference. maybe like
make vs ninja. But Meson or Cmake vs configure, HUGE difference...
The larger the project, the slower configure can be.
Peter Stuge
Nov 24, 2017, 7:30:03 PM11/24/17
to
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
> take the same amount of time and is super slow.
fairly expensive.
But I think the problem is more with poorly written configure source,
which is the argument about mastering..
> On small projects configure can take longer than compile... Configure
> is my main gripe against make/autotools. Plus all the other stuff,
> auto-reconf, autogen, etc.
to all other options. The tight integration between configure and
cross-toolchains is also a very strong point.
> The larger the project, the slower configure can be.
difficult to write good source.
//Peter
William L. Thomson Jr.
Nov 24, 2017, 8:00:02 PM11/24/17
to
On Sat, 25 Nov 2017 00:20:38 +0000
Peter Stuge <pe...@stuge.se> 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 still
> fairly expensive.
>
> But I think the problem is more with poorly written configure source,
> which is the argument about mastering..
Not sure what can be done for minimal ones.
Peter Stuge <pe...@stuge.se> 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 still
> fairly expensive.
>
> But I think the problem is more with poorly written configure source,
> which is the argument about mastering..
Meson 1.20s
https://travis-ci.org/Obsidian-StudiosInc/entrance/builds/291848344#L1033
Before I switched to meson
Configure/autotools 5.52s
https://travis-ci.org/Obsidian-StudiosInc/entrance/builds/270985567#L963
Original configure I dropped for meson
https://git.enlightenment.org/misc/entrance.git/tree/configure.ac
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
#secondsmatter :)
> > On small projects configure can take longer than compile...
> > Configure is my main gripe against make/autotools. Plus all the
> > other stuff, auto-reconf, autogen, etc.
>
> configure having zero dependencies is the killer feature compared
> to all other options. The tight integration between configure and
> cross-toolchains is also a very strong point.
Meson requires python, so that alone has a big dependency chain. Which
some what surprises me so many with libraries are going that route. I
guess they figure it is not core, python likely to be present.
Or who cares about end users, its all about saving devs time, no clue.
#mesonbandwagon
> > The larger the project, the slower configure can be.
>
> Doesn't have to be, but it's easy to write poor configure source and
> difficult to write good source.
fast configure. Beyond say the one for asspr.
Peter Stuge
Nov 24, 2017, 8:50:02 PM11/24/17
to
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.
> 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
> #secondsmatter :)
Yeah! :)
> The dependency aspect I agree with 100%. I think even cmake has more.
> Or who cares about end users, its all about saving devs time, no clue.
> #mesonbandwagon
yes, it's all optimization for development time, which makes some sense.
//Peter
Peter Stuge
Nov 24, 2017, 8:50:02 PM11/24/17
to
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
> 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
AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman])
foreign in particular if you would like to skip the various UPPERCASE
files in the project root.
//Peter
0 new messages