G'MIC extremely slow to compile - fix available

Software G'MIC
1

Hello

G’MIC takes a very long time to compile.

The build times are terrible because each and every binary recompiles and links as an object gmic.cpp - which is not only big, but includes the huge header CImg.h. The solution would be to convince upstream to allow linking against libgmic.

I started to implement myself the use of the shared library for all binaries that currently link the object statically and I’ll contribute it upstream when I’m done.

The patches were sent upstream, but upstream does not understand why I would want to do that instead of compiling and installing that common code for each and every one of those six binaries

https://bugs.gentoo.org/633950#c10

@David_Tschumperle would you please consider adopting those patches for 2.2.0?

2

Hello Morgan,

This has been discussed before here : optionally link the binaries against the dynamic library by stefantalpalaru · Pull Request #29 · dtschump/gmic · GitHub
Basically, it is now possible to link each executable with a compiled libgmic (with current git version).
It is not desirable though, as the different interfaces enable different features when compiling the file gmic.cpp (and each feature comes with dependencies to external libraries).

For instance, it is desirable for the cli interface to have all the input/output format support enabled for JPEG, PNG, TIFF, etc… This is not desirable for the plug-in. The plug-in gets image data mainly from the host software and it doesn’t have to know how to read float-valued TIFF files.
Making the plug-in depend on a common libgmic that would be used for all interface means adding a lot of dependencies for the users of the plug-in only.

We already have issues with users complaining about the high number of needed .dll files on Windows, or mismatching library versions when using the linux executable provided on the web page. I don’t want to manage useless extra-dependencies for the users of the plug-in.

I understand that if you want to install all G’MIC interfaces together (which is apparently what the Gentoo packager wants to do), then it is useless to compile gmic.cpp multiple times, but this is not the common use case. On other distros, packagers split the different G’MIC interfaces into several packages, so that people who wish to get the plug-in installed only are free to do so.

So, definitely I won’t make a shared libgmic library file shared amongst all the G’MIC interfaces the default. But I repeat what I already said : this is currently quite easy to compile a shared libgmic and use it for all the G’MIC interfaces (plug-in, cli,…). The packager can do it.

I’d be glad to help if anybody ask, except the packager we are talking about who is clearly too rude and unmannerly.

1 Like
3

maybe just make it a configure/cmake option so it really is just a flag for a packager?

4

The changes I’ve made have unfortunately broken the cmakefile we provided in the past, so I’ve removed it. I’m really not familiar enough with cmake to create a new working CMakeFiles.
But if someone wants to put his hands in this (and is ok to maintain it!!), he is welcome, of course.

5

I am pretty sure you could have handled the few needed change that might have been needed instead of just deleting it again.

6

Thanks for looking into this @David_Tschumperle

7

Maybe another thing : the patch submitted by the packager who complains was not accepted at time of submission, and is now not compatible with current version of git master.
It seems he was a bit upset about that so I doubt he’ll try to contribute again on the CMakefile, but that how life goes. I prefer to have less friendly contributors than more rude ones.

8

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 :wink:

9

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)
10

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 :wink:

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… :stuck_out_tongue:

Is this something that could work from your perspective? If so, I’ll try to contact the Gentoo dev…

3 Likes
11

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.

12

Well, that’s what I’m offering… :wink:

I’ll try to get in touch with the Gentoo developer.

13

Ok, so I have permission to use the patches. He’s actually a Gentoo user as well, not a developer. My bad :slight_smile:

I’ll probably pick this up later this week.

14

@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.

15

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.

16

But fast on older processors? :wink:

17

Who knows :stuck_out_tongue:

18

Here we go: Add support for the cmake build system again by saknopper · Pull Request #39 · dtschump/gmic · GitHub

1 Like
19

Thanks @saknopper, would you prefer we discuss possible issues here or on github ?

20

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.