CMake build system for G'MIC

Software G'MIC
21

I changed line 30 to
SET(COMPILE_FLAGS " {COMPILE_FLAGS} -mmacosx-version-min=10.8 -std=c++11 -stdlib=libc++ -Wno-error=c++11-narrowing -Wc++11-extensions -fpermissive") and line 146 to SET(EXTRA_LIBRARIES "-lpthread{EXTRA_LIBRARIES}")

Now it compiles at least. By the way, I never used -Dcimg_use_fftw3_singlethread

Linking does not work now for the plugin! cmake finds the apple png version, which is most possibly to old, libpng15 would be good, still I don’t know how to direct cmake!

22

On my osx system, and using jhbuild, I’ve never managed to compile the fftw library with threads support… however if you have it then I agree to remove that flag.

Concerning the PNG linking problem, the cmake configuration uses pkg-config to find the libraries and headers. Could it be that you need to set the PKG_LIBRARY_PATH environment variable to include the place where the newer PNG library is installed?

23

Hi, it works now!
I had some old things in /usr/local/lib concerning png. Your cmake builds now gmic_gimp and gmic with MacPorts. The plugin will only run with the MacPorts gimp version. The native Gimp crashes the plugin (library mismatches).

Perhaps your cmake approach helps to convince the officials to add the gmic plugin into the native bundle!

1 Like
24

Could you check if you have the libfftw3_threads library together with libfftw3 in your MacPorts?

Thanks!

25

I have updated the gist today. The CMakeLists.txt now provides ENABLE_XXX=ON/OFF options that match the gentoo use flags, except for FFMPEG. I have also fixed the RelWithDebInfo build type, and added an option to build the shared and static libraries.

Morgan: could you maybe check if it now integrates well with the gentoo build system?

I have included the first modification, but not the second one, because I want to find a better solution. Cmake complains that there is a trailing space in the library list, but at least on my system(s) it proceeds anyhow with the compilation…

@darix: did you already have a chance to give the cmake configuration a try?

1 Like
26

Hi, thanks for improvments. The extra space breaks the build on my system!

These are my MacPorts libfftw3 things:
~ $ ls /opt/local/lib/libfftw3
libfftw3.3.dylib libfftw3f.3.dylib
libfftw3.a libfftw3f.a
libfftw3.dylib libfftw3f.dylib
libfftw3_threads.3.dylib libfftw3f_threads.3.dylib
libfftw3_threads.a libfftw3f_threads.a
libfftw3_threads.dylib libfftw3f_threads.dylib

27

@KaRo: Ok, I have updated the gist with a patch that avoids extra spaces after the list of libraries.

The syntax is rather ugly for the moment, but it should work until I find a clear solution…

28

Hmm, I don’t know what you have changed, still now the build breaks because of errors concerning magick and seamingly Release build does not optimize anymore! The error appears also with MAGICK disabled!

[ 33%] Linking CXX executable gmic_gimp
Undefined symbols for architecture x86_64:
“Magick::InitializeMagick(char const*)”, referenced from:
cimg_library::cimg::Magick_info::Magick_info() in gmic.cpp.o
cimg_library::cimg::Magick_info::Magick_info() in gmic_gimp.cpp.o
“Magick::Color::Color(char const*)”, referenced from:
cimg_library::CImg::save_magick(char const*, unsigned int) const in gmic.cpp.o
cimg_library::CImg::save_magick(char const*, unsigned int) const in gmic.cpp.o
cimg_library::CImg::save_magick(char const*, unsigned int) const in gmic.cpp.o
…

29

Hmm, I don’t know what you have changed, still now the build breaks because of errors concerning magick and seamingly Release build does not optimize anymore! The error appears also with MAGICK disabled!

By the way I never added opencv in the plugin!

[ 33%] Linking CXX executable gmic_gimp
Undefined symbols for architecture x86_64:
“Magick::InitializeMagick(char const*)”, referenced from:
cimg_library::cimg::Magick_info::Magick_info() in gmic.cpp.o
cimg_library::cimg::Magick_info::Magick_info() in gmic_gimp.cpp.o
“Magick::Color::Color(char const*)”, referenced from:
cimg_library::CImg::save_magick(char const*, unsigned int) const in gmic.cpp.o
cimg_library::CImg::save_magick(char const*, unsigned int) const in gmic.cpp.o
cimg_library::CImg::save_magick(char const*, unsigned int) const in gmic.cpp.o
…

30

Ooops!!! I skipped by mistake a couple of crucial lines in my latest update of the gist, sorry for that!

Linking of graphicsmagick should be OK now (tested under linux), as well as optimisations in Release build target.

I will also check if OpenCV is allowed/needed for the gimp plug-in.

31

Hi, still an error during
[100%] Linking CXX shared library libgmic.dylib
ld: unknown option: -soname
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libgmic.dylib] Error 1
What about the space? I have put back your test for apple!

diff ~/Desktop/CMakeLists.txt ~/sw/gmic/CMakeLists.txt
88,92c88
< if(APPLE)
< set(COMPILE_FLAGS " {COMPILE_FLAGS} -Dcimg_use_fftw3_singlethread") < else(APPLE) < set(EXTRA_LIBRARIES "{EXTRA_LIBRARIES} -lfftw3_threads")
< endif(APPLE)

set(EXTRA_LIBRARIES “{EXTRA_LIBRARIES} -lfftw3_threads") 168c164,168 < SET(EXTRA_LIBRARIES "-lpthread {EXTRA_LIBRARIES}”)

32

Indeed, the -soname option should not be there for OSX. I updated the gist again, let’s hope this is the last iteration for the time being… :unamused:

33

Hi, some remarks from my Mac point of view:
It would be perhaps good to add a flag for pre_release. Actually after building with cmake only version 1.7.5 appears.
On my mbp to build the release lasts about 4h! Perhaps a flag for -Ox could be helpful.
The build of the plugin is actually only usable with (in my case) the MacPorts build of gimp. I have tried it with the native Mac Gimp build and with the ones from GimponOSX and Partha without success, either segfaults or library mismatches occur. So still there is the nasty situation with the quite different release frequency of Mac Gimp builds and g’mic and the therein used libraries.
If I consider the user community there are

  • Gimp user, mostly without any development environment, neither homebrew, Macports, fink, … They need some sort of packaged plugin including the necessary libraries. I don’t know how to prepare that.
  • gmic cli user for more advanced data processing, multi-dimensional. They have typically also not the environment. Perhaps for these a packaged version a la Windows would be helpful too.
  • libgmic user: That is the real developer community. They do not even need the cmake

Perhaps there are some ideas how to improve the situation? At least the cmake is a good step in this direction.

34

Where do you check for the version? The plug-in or the CLI interface?

Anyhow, this might be more a question for David…

35

pre_release has to be given from outside, look into Davids Makefile. AFAIK there is only the version as you use it!

36

Now I see what I mean… in the current Makefile I see that the “prerelease tag” is set from the build date. However, I would be strongly in favour of using a different way of tagging the pre-release, because

  • the build date has no direct relationship with the software version (you could build an older version after a more recent one, for whatever reason)
  • I could not find any simple way to tell cmake to insert the build time in the compiler invocation (the cmake configuration time is easy to retrieve, but is even less meaningful)

IMHO, the ideal solution would be to compile from a local copy of the git repository, and use the reference to the most recent commit as the pre-release tag.

For the time being, would it be acceptable to pass the pre-release tag as an option of the cmake command (something like -DPRERELEASE_TAG=08-11-2016)?

37

Yes, why not. Maybe without hyphen in a similar fashion as David do? The latest commit date would be very good, still how to get it? The pre_release date of builds by David can be found in the documentation. That is where I look, if a new git build might be necessary.
For me and possibly others, it should only be a hint for the pre_release. Empty tag might mean stable release?

38

I’ve modified the cmake configuration by adding a PRERELEASE_TAG option.

If you set the tag like that:

cmake -DPRERELEASE_TAG="20160812"...

then the

-Dgmic_prerelease=\"${PRERELEASE_TAG}\"

preprocessor macro will be inserted in the compiler flags.
If the PRERELEASE_TAG is not set, the -Dgmic_prerelease preprocessor macro is not added and the code is considered as an official release.

What do you think?

39

You could use __DATE__ and __TIME__ in the code.

40

Very good, only use Davids method: mmddyy, still a bit unfamilar!