On Sat, Jan 21, 2017 at 5:24 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
[...]
> i7 desktop: (autogen) (make) (eina_cpu.c) (eina_cpu.h) ()
> autotools: 27.802 4.306 0.571 1.234 0.097
> cmake ninja: 1.283 2.278 0.160 0.636 0.014
> cmake make: 1.632 3.142 0.234 0.787 0.064
>
> pi3:
> autotools: 477.870 62.640 6.853 16.337 1.313
> cmake ninja: 15.892 35.931 2.611 9.627 1.365
> cmake make: 19.358 38.991 0.961 1.161 0.921
>
> so dumping automake and libtool buys raw build speedups of like 2x. doing any
> editing of code is massively faster as just far less is built AND it's built
> faster. the autogen (configure/autotools) part is MANY MANY MANY times faster.
> even assuming it'll get 3x slower once we check everything with cmake... it's
> still 5-10 TIMES faster.
currently cmake's configure does very barebone checks, such as types
and the likes, but even that I want to improve by taking some
shortcuts such as "if(LINUX AND GLIBC_GOOD_ENOUGH)" would assume you
run a sane system and skip checking for stupid stuff. Same for
compiler checks, we do lots of flags we know exist in newer compilers,
so we could easily add an 'if' and just use the flags, not generate
and compile one single test with that. Granted we could also do some
of that in autootols, but some parts are trickier to do.
> the simple version of this is: it looks like cmake doesn't do stupid relinking
> or rebuilds it doesn't need to that i thought we'd have to fight. so it just
> got better. cmake is seemingly right out there in terms of speed. for a
> GENERIC
> build system tool that should/can handle anything it seems to be handily fast.
I configured it so it will require a build directory and inside that
directory I shadow the system installation without "prefix", thus you
end with "lib", "bin" and so on. They also use rpath to set paths to
find the binaries, resetting those to "" (empty) at the time of
installation, which is faster than relinking.
Also note that cmake itself is just involved at the first moment,
later you just run pure make/ninja commands. The make usually takes
some helpers to produce progress and colors. There ninja is usually
faster since it creates a full blown build.ninja with everything.
Seems your RPI3 is slower with ninja than make, one reason may be IO?
AFAIR ninja use command files and pass those to GCC with "@filename"
instead of super long command lines. However opening and reading those
small files may be hurting your build, since you're not actually
compiling stuff due ccache.
> what i see here is a major leap in productivity if we moved to cmake. i now
> "officially" like cmake. :) this would be a huge win for us... even if we have
> to wrestle in a make dist and distcheck. the option of ninja is a "a bit
> faster than gnu make and in some cases a lot faster" option. but really cmake
> is the key.
>
> so i guess... bikeshedding ... is there any reason to not use cmake that would
> override all the benefits? i cannot think of one.
I'd like to complement with: simpler rules and usage for efl developers.
With automake you can't autogenerate anything (at least I never found
a may to apply m4 rules there), then you keep repeating patterns for
modules and all, that results in slightly different versions of the
same thing as one is updated and the other isn't.
with cmake and other build systems I can instruct them to understand
efl's well structured source tree and automatically do stuff for us.
My plan is for the final CMakeLists.txt to foreach(l in src/lib/*)
call EFL_LIB(${l}), then it will automatically do:
- check if library is enabled
- include src/lib/${l}/CMakeLists.txt to get SOURCES, LIBRARIES,
PUBLIC_LIBRARIES, PUBLIC_HEADERS...
- create static/dynamic library (we can even automate libefl-single.so here)
- write ${l}.pc (also simpler to automate libefl-single.pc and make
all others just Require: efl-single)
- include src/bin/${l}/CMakeLists.txt or
src/bin/${l}/*/CMakeLists.txt and compile all binaries automatically
linking with the library ${l}
- include src/modules/${l}/*/*/CMakeLists.txt and compile all modules
(with optional scope) linking with ${l} (if dynamic) or linking ${l}
with module.a (if static module)
- include src/tests/${l} or src/tests/${l}/*/CMakeLists.txt and
compile all tests, linking with ${l} and adding to ctest testing
runner.
You can compare 3 files with src/Makefile_Eina.am:
src/lib/eina/CMakeLists.txt
src/modules/eina/mp/one_big/CMakeLists.txt
src/tests/eina/CMakeLists.txt
see we do not need to provide src/bin/eina/eina_btlog/CMakeLists.txt
as it's a single file source that just links with eina.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
