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 i
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.
> #secondsmatt
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 still
> fairly ex
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 configur
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.
https://github.com/apache/inc
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 bu
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: That'
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 l
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: there are basical
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)
> > DEPEND="dev-util/ninja"
> >
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 must not depend
on dyna
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 case where Gentoo c
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}
>> + : ${CMAKE_MAKEFILE_
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 y
14 matches
Mail list logo
