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
