gmic 3.1.5

[cho-m]

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you ensured that your commits follow the commit style guide?
• [ ] Have you checked that there aren't other open pull requests for the same formula update/change?
• [ ] Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• [ ] Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• [ ] Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[Bo98]

Before merging, please compare the install tree of this version compared to the previous version we shipped.

Looks like Linux distros are split between reviving the CMake file and patching the Makefile. I agree the Makefile is probably better maintained but the dylib issue needs sorting.

[cho-m]

Before merging, please compare the install tree of this version compared to the previous version we shipped.

I did some basic comparison previously (will update with actual info in a bit):

• Main issue is shared library naming. Currently uses .so .so.3 .so.315 on all OS.
• We lose CMake files, but that is unavoidable unless we restore CMake build
• There is an extra header getting installed for I think the C API, which we don't build library for.

[cho-m]

/usr/local/Cellar/gmic/3.0.1

├── COPYING
├── INSTALL_RECEIPT.json
├── README
├── bin
│   └── gmic
├── include
│   └── gmic.h
├── lib
│   ├── cmake
│   │   └── gmic
│   │       ├── GmicConfig.cmake
│   │       ├── GmicTargets-release.cmake
│   │       └── GmicTargets.cmake
│   ├── libgmic.1.dylib
│   ├── libgmic.a
│   └── libgmic.dylib -> libgmic.1.dylib
└── share
    ├── bash-completion
    │   └── completions
    │       └── gmic
    └── man
        └── man1
            └── gmic.1

/usr/local/Cellar/gmic/3.1.5

├── COPYING
├── INSTALL_RECEIPT.json
├── README
├── bin
│   └── gmic
├── etc
│   └── bash_completion.d
│       └── gmic
├── include
│   ├── gmic.h
│   └── gmic_libc.h
├── lib
│   ├── libgmic.a
│   ├── libgmic.so -> libgmic.so.3
│   ├── libgmic.so.3 -> libgmic.so.315
│   └── libgmic.so.315
└── share
    └── man
        ├── fr
        │   └── man1
        │       └── gmic.1.gz
        └── man1
            └── gmic.1.gz

[carlocab]

the dylib issue needs sorting

I agree it would be nicer to ship libraries as dylibs, but the linker seems to handle MH_DYLIBs with a .so extension just fine. ghostscript does this after we dropped the dylib patch (which I'm not too happy about, but it seems to not have broken much). Or are we worried about clients that currently link to an install name with a dylib extension?

Edit 1: Oh, wait, it's not ghostscript. It's some other formulae. Let me try to find it...

Edit 2: No, I am thinking about ghostscript, but it's a different issue: https://github.com/Homebrew/homebrew-core/pull/86026#issuecomment-944921746

[cho-m]

Related upstream issue on CMake files: https://github.com/GreycLab/gmic/issues/396

Taking a look at list of contributors at https://gmic.eu, it looks like there was one person who maintained CMake builds, so I'm guessing there is lack of support there.

The binaries do link to .so libraries and at least run correctly.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[iMichka]

==> Analytics install: 51 (30 days), 153 (90 days), 915 (365 days) install-on-request: 51 (30 days), 153 (90 days), 910 (365 days) build-error: 2 (30 days)

The install counts are quite low. If this is too complex to maintain / to update, we could deprecate it with :does_not_build

Whatever we do: if upstream dropped the Cmake part, let's not rely on that. Else we will have to maintain our own set of patches.

[jonchang]

bump to 3.1.6 and fix the so/dylib issue by cheekily using a macports patch ;)

[BrewTestBot]

:robot: A scheduled task has triggered a merge.