Makefile doesn't fit for downstream packagers

[t0b3]

I just got aware that the src/Makefile doesn't fit for downstream packagers i.e. on Gentoo and gmic is announced to be dropped entirely. (gentoo bug 916289)

My quick search lead to some patches on gentoo - OTOH I didn't see any upstreaming back here...

So my motivation is to enable upstreaming gentoo patches @dtschump Can you have a look at those patches and see if you could integrate them in gmic to facilitate downstream packagers life?

• gentoo patches

I also whish you could

• add Github Action CI tests (would you be open for some PR?)
• elaborate an easy working make process for downstream (I don't know the exact pain points though)
  • Arch may serve maybe with it's CMake based build process :smile:

[dtschump]

Hello. No time for looking at this actively right now, unfortunately. But I'd be happy to review a PR that makes things better for Gentoo maintainers, assuming of course that this doesn't break the packaging for other distributions (which don't seem to have any particular problems with the current state of the Makefile). About CMake : Personnally, I'm not using at all and I don't have special interest in providing a CMakeList (there is one in gmic/resources/ anyway). I'm open to PRs that would improve this situation (I had some in the past), but with the guarantee that this will be maintained over time.

Because it's too painful to have to maintain and synchronize multiple ways of compiling a project, so I prefer keeping just one that I can manage, than two where one cannot be maintained.

[eli-schwartz]

My quick search lead to some patches on gentoo - OTOH I didn't see any upstreaming back here...

The gentoo maintainer claimed that this did in fact used to happen, but the gentoo maintainer gave up because attempts to contribute got nowhere.

Sadly, @dtschump has chosen to totally delete the repository, and delete all bug reports and pull requests in the process, so there is no way to prove that one way or the other now. This was not at all necessary -- the stated reason was a lack of familiarity with git, but even with that, the standard, correct way to handle this is to simply delete all files in the repository and commit a replacement as one giant patch. But even if that wasn't done, the other standard and correct way to handle this is to rename the repository on the GitHub UI and create a new repository while leaving the other one behind as "historical". This issue was brought up in #1 but requests to "please restore the deleted repository and I can help you smooth things over if you need help" were entirely ignored. It is now long past the 90 days where recovery of bug reports and pull requests is possible (but stitching back together the historical changelog is still possible even so).

I'm not suggesting that the gmic project is trying to hide something, for the record. But apparently the Gentoo maintainer's opinion on the topic is that:

• the current Makefile is worse in every regard compared to the cmake files that were there before the Makefile
• the Makefile was introduced to solve problems with the cmake, that the Makefile sadly did not fix but were easy to solve in cmake and harder to solve in a pure Makefile (and I suppose, offers and pull requests to fix it weren't successful)
• the radio silence in #1 is characteristic of the project, and not worth continuing to struggle with when the software can simply be deleted from Gentoo, freeing up the gentoo maintainer's time for working on other things instead

Whatever else is going on, there does seem to be a clear disconnect between what users believe they can expect from gmic, and what gmic believes it is trying to offer in the way of expectations. And this disconnect is in the realm of communications, rather than something easy to solve like code -- you can't submit a pull request to fix the former. :(

[dtschump]

the Makefile was introduced to solve problems with the cmake, that the Makefile sadly did not fix but were easy to solve in cmake and harder to solve in a pure Makefile (and I suppose, offers and pull requests to fix it weren't successful)

The Makefile has always been there, from the start, as this is how I managed to compile gmic. It was there long before we got a first contribution to get a CMakeList. So your assertion is false. As I've said it before, I'm not familiar enough with cmake (and don't have time for investigation), and at one point, the existing CMakeList was not functional, so I moved it to the folder resources/. It's good to have people submitting new files, it's even better when they decide to maintain it over time. My position is that it's better to have nothing at all than a broken CMakeList that causes more problems than it solves.

I think you've got the wrong idea about the project's strategy. We have nothing special to hide, and the problem with the git repository was indeed a mistake on my part. It can happen. You can't master everything, especially when you have to take care of everything. It would be more constructive if you contributed rather than just criticizing.

Whatever else is going on, there does seem to be a clear disconnect between what users believe they can expect from gmic, and what gmic believes it is trying to offer in the way of expectations

It's not necessary to be so harsh. I'm not sure this discussion is leading to anything very constructive. if Gentoo's maintainers decide to stop packaging G'MIC, t's their decision. No need to blame upstream. I'm waiting for your PRs.

[eli-schwartz]

But I'd be happy to review a PR that makes things better for Gentoo maintainers, assuming of course that this doesn't break the packaging for other distributions (which don't seem to have any particular problems with the current state of the Makefile).

This is not a Gentoo specific issue either way:

OpenSUSE: https://build.opensuse.org/package/view_file/openSUSE:Factory/gmic/gmic.spec?expand=1

%build
# Build gmic
# Starting with gmic 3.1.0, the gmic dev replaced their CMake build system with a non-configurable Makefile...
sed -i 's#LIB ?= lib#LIB ?= %{_lib}#' src/Makefile

# Breaks compilation for a couple archs
sed -i 's#-mtune=generic##' src/Makefile

# Broken rpath
sed -i 's# -Wl,-rpath,.##' src/Makefile

# The file is moved post-install in a directory not owned by gimp
sed -i 's#/usr/lib/gimp/2.0/plug-ins#%{gmic_datadir}#' src/gmic_stdlib.gmic

# There's no concept of build order in the crappy Makefile provided
EXTRA_CFLAGS='%{optflags}' NOSTRIP=1 %__make lib %{?_smp_mflags}
EXTRA_CFLAGS='%{optflags}' NOSTRIP=1 %__make cli_shared %{?_smp_mflags}

MacPorts: https://github.com/macports/macports-ports/blob/master/science/gmic/files/patch-src-Makefile.diff https://github.com/macports/macports-ports/blob/master/science/gmic/Portfile (The former fixes Makefile issues, the latter passes even more flags to the Makefile, then completely ignores the install step and manually copies over installable files)

Mageia: http://sophie.zarb.org/rpms/6771f9d9ec5bd49641a24509fd65bb58/files

• gmic-3.2.0-ldflags.patch (respect LDFLAGS)
• gmic-dont-add-rpaths.patch (remove problematic rpath)
• gmic-3.2.0-mga-optflags.patch (remove problematic -flto / -O3 / -mtune)

Homebrew: https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gmic.rb

• grabs a macports patch for soname

  def install
  # The Makefile is not safe to run in parallel.
  # Issue ref: https://github.com/dtschump/gmic/issues/406
  ENV.deparallelize
  
  # Use PLUGINDIR to avoid trying to create "/plug-ins" on Linux without GIMP.
  # Disable X11 by using the values from Makefile when "/usr/X11" doesn't exist.
  args = %W[
    PLUGINDIR=#{buildpath}/plug-ins
    USR=#{prefix}
    X11_CFLAGS=-Dcimg_display=0
    X11_LIBS=-lpthread
    SOVERSION=#{version}
  ]
  system "make", "lib", "cli_shared", *args
  system "make", "install", *args, "PREFIX=#{prefix}"
  lib.install "src/libgmic.a"

(Hey, there's a broken link to an issue that homebrew submitted, which disappeared after the repository was deleted.)

guix: packages 3.0.0 with a cmake build system

Cygwin: https://cygwin.com/cgit/cygwin-packages/gmic/tree/

• 4 patches
• cygport itself manually installs all files, does not use make install

Debian: builds with a cmake build system (version 2.9.4)

[nedko]

I applied the patches from current gentoo gmic-3.3.1.ebuild in https://github.com/LADI/gmic branch "gentoo" (the default). The patch hunk for gmic-qt/gmic_qt.pro failed, a failure which seems to be safe to ignore.

[stefantalpalaru]

I've been packaging gmic in my Gentoo overlay for the past 9 years: https://github.com/stefantalpalaru/gentoo-overlay

Every release after the first one is using CMake. Even when upstream removed its "CMakeLists.txt", I carried a fixed & improved copy in a patch. Tried to submit it upstream, but upstream decided I was not nice enough. Someone else, decidedly nicer, submitted it instead. Upstream moved it in a subdirectory, so it doesn't work out of the box :-)

Anyway, after mv resources/{cmake,CMakeLists.txt} . it does work. For some reason, the official Gentoo maintainer could not figure this out and decided to struggle with the franken-makefile instead.

[dtschump]

If the CMakeLists.txt file works, I'll move it to the root directory. I'm pretty sure this was not working for me when I moved it to the resources/ folder.

[dtschump]

I confirm this works for me.

https://github.com/GreycLab/gmic/commit/ce6e427d93bb19beee8d6e3d5446ed04b48a103a

[dtschump]

FYI, G'MIC version 3.2.2 has been released, with the CMakeLists.txt included by default.

[stefantalpalaru]

version 3.2.2 has been released

That's actually 3.3.2 :-)

I know because I already packaged it: https://github.com/stefantalpalaru/gentoo-overlay/commit/5eb4c71c42011eb3c09ffe82d82b43959952b6ca

[dtschump]

Yes sorry, 3.3.2 indeed :)

[t0b3]

@stefantalpalaru works perfect here THX @dtschump thank you :smile:

[iandoug]

Are these fixes going to find their way back into the main Gentoo tree? I use gmic occasionally and do not want to remove it.

Thanks.

[t0b3]

:+1:

[dtschump]

Hello. I'd be interested if someone could modify the CMakeLists.txt file so that using make install with the auto-generated Makefile installs some of the G'MIC resources files in usr/share/gmic/. Like it is done in the hand-made Makefile located in src/:

    @if [ -f ../resources/gmic_cluts.gmz ]; then cp -f ../resources/gmic_cluts.gmz $(DESTDIR)$(SHARE)/gmic; fi
    @if [ -f ../resources/gmic_denoise_cnn.gmz ]; then cp -f ../resources/gmic_denoise_cnn.gmz $(DESTDIR)$(SHARE)/gmic; fi
    @if [ -f ../resources/gmic_fonts.gmz ]; then cp -f ../resources/gmic_fonts.gmz $(DESTDIR)$(SHARE)/gmic; fi
    @if [ -f ../resources/gmic_lightleaks.gmz ]; then cp -f ../resources/gmic_lightleaks.gmz $(DESTDIR)$(SHARE)/gmic; fi

Would it be possible? Thanks.