#43 New release

[Tobias Fischer]

Hi there,

We are running into issues in packaging GraphicsMagick for conda-forge on Windows (https://github.com/conda-forge/graphicsmagick-feedstock/). We are having trouble to compile projects because of the problems described in https://sourceforge.net/p/graphicsmagick/discussion/250738/thread/a959e64070/?limit=25

The problem already seems to be fixed, but no new version has been released since. Would it please be possible to release a new version?

Many thanks,
Tobias

[Bob Friesenhahn]

It is interesting that this release request is related to Microsoft Windows. The primary inhibitor to a release is the Microsoft Windows build using Visual Studio. Repeated pleas have been made for Windows experts to assist with updating the Microsoft Windows build but only one person has been willing to offer even a few minutes of their time, and unfortunately it does not address the major issues.

Changes in third party libraries like libtiff and JasPer require using Visual Studio 2015 or later since they require real C'99 support. Once the code for these libraries is updated (which they still need to be), then it will not be possible to use older compilers without considerable effort (e.g. to emulate C'99).

Since the 'configure' program only produces old-style Visual Studio project files and modern Visual Studio is astonishingly slow at updating the project file format (e.g. 20 minutes vs 20 seconds) some work is desired to the 'configure' program so that it can write modern Visual Studio project files.

Since there seems to be so little interest in Microsoft Windows (except for the massive number of downloads/installs of the binary package) I may decouple support for the Microsoft Windows installation package from the GraphicsMagick release schedule since it is severely hindering releases.

One person (a person who only uses Microsoft Windows for purposes of GraphicsMagick releases and to update his Garmin GPS) is not reasonably able to accomplish everything in his spare time.

It is not immediately clear to me if conda-forge uses Visual Studio, or if it uses GCC, or if it uses binary packages built by others.

[Tobias Fischer]

Dear Bob,

Many thanks for your response!

I might have some good news for you. In conda-forge (see https://conda-forge.org/docs/user/introduction.html) we package GraphicsMagick. GraphicsMagick is very easy to install via conda-forge - one simply installs conda first (see e.g. https://github.com/conda-forge/miniforge) and then runs "conda install graphicsmagick -c conda-forge". That's still not as convenient as installing GraphicsMagick via a graphical installer though - this is why a tool called 'conda constructor' was written: https://github.com/conda/constructor - this enables building an executable with a graphical installer; in this case installing conda is not needed either. Note that this works for Windows, Linux and MacOS (even for arm64!).

We avoid the trouble with the 'configure' program by using a modern cmake build. (see https://github.com/conda-forge/graphicsmagick-feedstock/blob/master/recipe/CMakeLists.txt for the CMakeLists). The CMakeLists.txt is then used to build GraphicsMagick with Visual Studio (one could also use clang if one wanted to do so): https://github.com/conda-forge/graphicsmagick-feedstock/blob/master/recipe/bld.bat We have up-to-date versions of the libtiff etc libraries in conda-forge, so that's not an issue at all.

If GraphicsMagick were hosted on GitHub, it would be trivial to set up a GitHub action to build GraphicsMagick via conda-forge (and use 'conda constructor' to build the graphical installer).

If you have interest in releasing GraphicsMagick via conda, please let me/us know; I think it would be fairly easy to get this going. Even if you don't wish to do so, note that we build from sources - hence we wouldn't mind at all if the Windows install package is separate from the normal release cycle.

Best, Tobias

[Bob Friesenhahn]

On Sat, 13 Nov 2021, Tobias Fischer wrote:

We avoid the trouble with the 'configure' program by using a modern
cmake build. (see
https://github.com/conda-forge/graphicsmagick-feedstock/blob/master/recipe/CMakeLists.txt
for the CMakeLists). The CMakeLists.txt is then used to build
GraphicsMagick with Visual Studio (one could also use clang if one
wanted to do so):

That is good. GraphicsMagick should be supporting Cmake directly in
order to avoid the common problem that only one subset of the build
configurations is supported. With care this could support the
requirements of external Cmake users as well.

There is a Windows vcpkg for GraphicsMagick but it only supports one
build configuration, and last I checked, it does not support building
the 'gm' utility at all.

If GraphicsMagick were hosted on GitHub,

GitHub means git (which commonly brings a completely different
communal development process) and I seem to be git-challenged.

If you have interest in releasing GraphicsMagick via conda, please
let me/us know; I think it would be fairly easy to get this going.
Even if you don't wish to do so, note that we build from sources -
hence we wouldn't mind at all if the Windows install package is
separate from the normal release cycle.

I prefer if GraphicsMagick is build system 'agnostic' in that it
should support the needs of mutiple users.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[Bob Friesenhahn]

New GraphicsMagick releases have been released since this issue was opened (including for Visual Studio) so it is believed that this request has been satisfied.