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…
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.
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.
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 !
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 ?
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 !
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).