On Mon, 23 Jan 2017 09:38:44 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> 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. generically yeah. i get it. for us though we can just split our build into stages and execute the next stage (eg needing to run eolian_gen and near the end run edje_cc) with a tmp install and LD_LIBRARY_PATH... :) > 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. yes. but if we stick to 1 subdir per target - we have to move targets out of their source subdir into this resulting tree. so it's a little nasty.. :/ > >> 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) indeed making this standardized would help. the best thing - find the majority pattern and convert those not int he majority to follow it. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
