On Fri, 20 Jan 2017 23:20:17 +0000 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
on the below. 1. i like the idea of 1 dir == 1 target (1 binary, 1 .so, etc.). it simplifies things. soi agree that a general move to this style of tree simplifies buid too. i like. 2. i actually fixed up the autotools to build the same things the current cmake attempt does. here are my numbers. first is my i7 desktop at home (32gb ram, ssd's, i7-4790K @ 4ghz). the second is my raspberry pi3 (4 core ARMv7 @ 1.2ghz, 1gb ram, system running off micro-sd card). this is unfair to autotools for the autogen stage (or cd build; cmake .. stage) and it still has all the other autoconf stuff for the rest of efl checked and generated... so take the left column with a fat grain of salt. we're likely 2-3x slower or so than we should be if really just checking the same stuff. numbers are in seconds taken. the first column (autogen) is ./autogen.sh --disable-static OR cd build; cmake .. or cmake -G Ninja ... time taken. the second column is a full "make everything" (libeina and eina_btlog and eina_modinfo). make -j 10 on i7, make -j5 on pi3 (with ninja -j 10 and -j 5 for ninja). the next column is me touch'ing eina_cpu.c to force some recompile. the next is touching eina_cpu.h likewise testing. the last () column is touching nothing and seeing what a noop "make" takes to figure out it has nothing to do. note my CC is set to ccache gcc and in all cases i had done a prior build and already "seeded" my ccache so this is not testing uncached builds like a packager or rare user of build would do. it's testing the kind of workflow a core developer will be using. 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. 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. 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. > Updated with one target per directory simplifications, euna_btlog and > eina_modinfo are examples of that, and as they are single file sources they > need no CMakeLists.txt, these are guessed in such cases. > > Instead of filling specific .pc.in templates, it now generate files based > on library variables. Much simpler and more scalable. > > Marcel will look how to transparently handle .eo files. > > > Em qui, 19 de jan de 2017 às 21:17, Gustavo Sverzut Barbieri < > barbi...@gmail.com> escreveu: > > > Hi all, > > > > > > > > Marcel Hollerbach did a nice work and started a branch > > devs/bu5hm4n/cmake-port > > > > > > > > After some review, I shared my experience with CMake and did a > > > > complement trying to simplify it: devs/barbieri/cmake > > > > (https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/cmake) > > > > > > > > As you can see, complexities are hidden from the user using some > > > > macros/functions defined in cmake/helper/EflMacros.cmake > > > > > > > > At the toplevel directory you simply say: EFL_LIB(eina) > > > > > > > > Then the macro will include whenever appropriate > > > > src/{lib,bin,modules,tests}/eina and do the right action. You can see > > > > from sub-CMakeLists.txt how simple they become, basically define some > > > > variables (which makes it simpler for us to change to a new build > > > > system next time). > > > > > > > > There are some restrictions in that, which I'd like to keep and > > > > instead of work-around in the build system, change the code to reflect > > > > that: > > > > > > > > - one library per directory, offenders are efreet_mime/efreet_thrash > > > > and possibly others; > > > > > > > > - modules should install > > > > > > ${libdir}/${libname}/modules/${scope}/${modname}/v-${VMAJ}. > > ${VMIN}/module.so, > > > > currently some libs miss "/modules", like ecore/system > > > > > > > > If you want to try it out, be aware that binaries are still not > > > > handled and eina_suite still doesn't work. And I'm forcing out-of-tree > > > > builds, so we fix that for once and for all: > > > > > > > > mkdir -p build && cmake -H. -Bbuild && cd build && make > > > > > > > > To address raster's complains about hard targets and so on: > > > > > > > > make eina > > > > > > > > builds eina checking dependencies, while: > > > > > > > > make eina/fast > > > > > > > > doesn't check dependencies, this is in GNU Make. Ninja doesn't offer such > > rule. > > > > > > > > I'm also offering targets for modules and tests: > > > > > > > > make eina-tests > > > > make eina-modules > > > > > > > > Everything should be placed in build/lib, build/bin and so on, so it > > > > will mimic the system installation and eina_prefix should be able to > > > > work (we're still missing the 'checkme' files). > > > > > > > > Although I know cmake from my years-ago usage, I'm not an expert that > > > > works with it every day, thus review of the CMake, particularly the > > > > macros is very helpful. > > > > > > > > From an user (EFL developer that doesn't mess with build system) point of > > view: > > > > > > > > - library configuration checks and options (cmake/config/eina.cmake): > > > > > > https://git.enlightenment.org/core/efl.git/tree/cmake/config/eina.cmake?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405 > > > > The idea is to isolate these complexities from source/headers as very > > > > few people will need to look at configure, but most developers need to > > > > touch file list. > > > > > > > > - library sources, headers (src/lib/eina/CMakeLists.txt): > > > > > > https://git.enlightenment.org/core/efl.git/tree/src/lib/eina/CMakeLists.txt?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405 > > > > > > > > - library module (src/modules/eina/mp/pass_through/CMakeLists.txt): > > > > > > https://git.enlightenment.org/core/efl.git/tree/src/modules/eina/mp/pass_through/CMakeLists.txt?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405 > > > > > > > > - library unit tests (src/tests/eina/CMakeLists.txt): > > > > > > https://git.enlightenment.org/core/efl.git/tree/src/tests/eina/CMakeLists.txt?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405 > > > > > > > > As you can see these files are very small, they basically define > > > > SOURCES, HEADERS, DEPENDENCIES, LIBRARIES... variables and these are > > > > used to execute CMake specific targets, set properties, etc. > > > > > > > > If we can settle on one-lib-per-dir, then we can even simplify those > > > > and remove ${libname}_ prefix, as done by modules we could specify > > > > SOURCES instead of eina_SOURCES. > > > > > > > > > > > > -- > > > > 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 -- ------------- 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
