Improvement in compilation times is actually strange, there are no reasons it should be faster to compile with cmake
. We have to check if the flags (e.g. optimization flags) passed to the compiler are indeed the same as the regular Makefile
Anyway, @saknopper has done a wonderful job for sure !
Thanks! Actually, if @KaRo is using the dynamic linking option it might be a lot faster to compile…
Otherwise it might be due to the lack of optimization flags by default for the cmake build.
Yes, I’ve just checked that, and doing cmake .
then, make
indeed compiles without optimization flags. This is a bit annoying, I think many users could be cheated by that, and get very slow binaries of gmic
as default.
Could we set the release mode as default ?
I did not use dynamic linking. In fact at least the cli is not optimized.
gmic follic tic +dilate_oct 31 erode_oct. 31 -. … toc
delivers an eight-fold time needed!
Actually, even with
cmake -DCMAKE_BUILD_TYPE=Release .
the generated Makefile
does not enable the optimization flags for the compiler. This is a big concern.
Right now, if packagers decide to use the current CMakeLists.txt
, they may end up with a wrong, unoptimized version of G’MIC !
I will fix it, don’t worry You haven’t made a new release yet right?
While you’re at it: You could also add some eye candy by streamlining capitalization (IF
, SET
vs. if
, set
) and modernizing with else()
and endif()
(where applicable).
You can run this script in the root of your repo to fix CMake command case and spaces between command and braces: