On Mon, Jan 23, 2017 at 3:19 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 21 Jan 2017 09:45:04 -0200 Gustavo Sverzut Barbieri > <barbi...@gmail.com> said: > >> 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. > > yeah. having more "we know on platform X feature x/y/z are exist andor/ arfe > done this way" and simply detecting which is nicest. though there is the > un-fun > thing s like "linux && glibc, linux && uclibc, linux && musl ..." for > starters... :( > >> > 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. > > i'm less of an rpath fan... i'd rather we use LI_LIBRARY_PATH instead at these > junctures...
https://cmake.org/Wiki/CMake_RPATH_handling says -DCMAKE_SKIP_RPATH=ON does what you want. But overall it helps usage without the need for nasty libtool-like scripts. However, with the build results being laid out exactly like they would in the system makes things much easier, eina_prefix should just work, etc. >> 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. > > well make/ninja with some calling out to cmake... but yeah. > >> 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. > > yes. ccache helps make the compile bit about as fast as it'll get so the other > parts show up... > >> > 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. > > i like the idea of a strict tree with a pattern to follow so it's easy to copy > & paste or re-use templates or just have simpler parent build rules that just > need some overrides (eg add the following include dirs and linking to this > binary vs the std template). > > now the question still stands... any good reasons not to cmake. what we need > is: > > 1. people willing to get dirty and help a move happen > 2. a plan of how to do that move with the least disruption and least pain > > i can see a stage 0 here... "prepare for it". so within autotool land move src > around a bit so we have "1 dir == 1 output target" like you describe so it's > easier to do the above you describe with cmake. > > another question is ... is it possible to have a hybrid system. for now have a > master configure and this re-cycles sub-configure-like features to run cmake > in > subdirs. that way we can port src/lib/eina and src/bin/eina for example > first ... then expand... then eg do efl and eo, then ecore, then ecore_con > then... so one thing at a time move over to cmake... and in the end nuke the > toplevel autotools configure and replace that with cmake. is this even sane? while this is possible, I believe it can be done real quick once we finish eina for real IF we add an extra step to "stage 0": - unify & simplify #define usage As Marcel noticed and I notice when I helped with the single tree unification, it's a nightmare to find out the defines, what people use and which are meaningful. So a review to also follow a pattern is needed and can be done in autotools before we move. An example is how to enable/disable modules and make them static, these are all different and in cmake I tried to make them auto-generated thus they must follow a pattern: EFL_${LIB}_MODULE_TYPE_${SCOPE}_${MODULE}_${TYPE} like: EFL_EINA_MODULE_TYPE_MP_CHAINED_STATIC EFL_EINA_MODULE_TYPE_MP_ONE_BIG_DYNAMIC Then it's my proposal for modules to be all converted to use something like that + the install directory structure to be the same, currently ecore is different, possibly others. But that goes to many, many things, like 3-4 variables to tell project version (VMAJ-like) -- 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
