Can you summarize what has caused the last version of the CMakeFiles not to work anymore? In other words, what has changed in the code?
Because the commit messages are a bit… uhm… sparse 
Basically, this is how you can compile the cli/gimp_gtk interfaces with a shared libcgmic. This is an extract from the Makefile, entry allshared: :
# All interfaces, sharing the same dynamic library
#--------------------------------------------------
allshared:
$(MAKE) "CFLAGS+=$(GMIC_CLI_CFLAGS) $(OPT_CFLAGS)" "LIBS+=$(GMIC_CLI_LIBS)" _allshared
_allshared: libgmic_shared.o
ar rcs libgmic_shared.a libgmic_shared.o
$(CXX) -shared -Wl,-soname,libgmic_shared.so.$(VERSION1) -o libgmic_shared.so libgmic_shared.o $(LIBS)
$(CXX) -o use_libgmic use_libgmic.cpp -L. -lgmic_shared $(LIBS)
$(CXX) -o gmic gmic_cli.cpp $(CFLAGS) -lgmic_shared $(LIBS)
$(STRIP) gmic$(EXE)
$(CXX) -o gmic_gimp_gtk gmic_gimp_gtk.cpp `gimptool-2.0$(EXE) --cflags` `gimptool-2.0$(EXE) --libs` $(CFLAGS) -lgmic_shared $(LIBS)
$(STRIP) gmic_gimp_gtk$(EXE)
libgmic_shared.o: check_versions CImg.h gmic_stdlib.h
$(CXX) -o libgmic_shared.o -c gmic.cpp $(PIC) $(CFLAGS)
Sorry for the late response, but I haven’t had time to really look into this.
I’ve been reading through the conversations ( optionally link the binaries against the dynamic library by stefantalpalaru · Pull Request #29 · dtschump/gmic · GitHub and cmake support dropped? · Issue #30 · dtschump/gmic · GitHub ) you’ve had with the Gentoo developer and to be honest it makes me quite sad to see how things turned out. Because I see 2 persons with good intentions that somehow can’t seem to co-operate.
So after thinking about it a bit and seeing that said developer already has pretty much everything in place to make a cmake-based build work again (gentoo-overlay/media-gfx/gmic at master · stefantalpalaru/gentoo-overlay · GitHub) I thought I could perhaps act as some kind of mediator to get this into the official gmic repository again. Bear in mind, I will initially just copy (while giving credits obviously) work already done by the Gentoo developer. So I hope you’re ok with that
After that, I’ll do my best to keep it working as gmic progresses. My reasoning for doing this is simple, I’m a Gentoo user and I’d like to get the most recent version of gmic in the gentoo package repository.
Also, I’m a (professional) software developer. So I know what I’m doing, kind of anyway… 
Is this something that could work from your perspective? If so, I’ll try to contact the Gentoo dev…
3 Likes
I’ve done some necessary modifications in the Makefile to reflect changes that was made on the G’MIC source code, and added a new Makefile entry allshared allowing the OP to fulfill his request.
The pull request proposed by the OP was not good enough to be included. And the modifications I made broke that pull request. After that, I got a really bad feedback from the OP despite the fact he was able to build G’MIC as he asked, with a shared library (he probably didn’t want to try my way, I don’t know why).
I’m not using cmake at all, I think it is not really useful for a small project like G’MIC, and anyway I’m not familiar enough with this tool to create and maintain a working CMakeList.
I like when people contribute, but what I’m asking is they also maintain their contributions when I’m not able to do it myself. We had a working CMakeList for the project for a while, but I think it is not working anymore, and nobody took the time to update it to make it work with the latest version.
I’d be happy to hear someone is OK to deal with it, as long as he also says he promise to maintain the CMakeList in the future, in case of changes.
Well, that’s what I’m offering… 
I’ll try to get in touch with the Gentoo developer.
Ok, so I have permission to use the patches. He’s actually a Gentoo user as well, not a developer. My bad 
I’ll probably pick this up later this week.
@saknopper I’m a Gentoo/Sabayon user, I can help test. I just compiled https://github.com/stefantalpalaru/gentoo-overlay/blob/master/media-gfx/gmic/gmic-2.2.1.ebuild today and it worked fine, though very slow.
Ah, that’s good to know!
Yeah, it’s basically a single file containing most (all?) of the source code. So the build process can’t take advantage of multiple cores which makes it slow to compile on modern processors.
But fast on older processors?
Who knows 
Here we go: Add support for the cmake build system again by saknopper · Pull Request #39 · dtschump/gmic · GitHub
1 Like
Hi, @saknopper, David, congratulations to the ccmake configuration file. Incredible reduction in compile time.
Some hints for builds would be helpful, for release and pre versions etc.
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 !
1 Like
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.
1 Like
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).
2 Likes