CMake support

[janisozaur]

What are the chances of you shipping CMakeLists.txt for CMake support? It is significantly easier to work with, especially in some more obscure platforms, like Windows. It would allow easy integration into Microsoft's vcpkg.

[Jehan]

How is CMake easier to work with on Windows? (real question, no trick, I just really want to understand what you mean because I never had any problems with autotools for Windows)

I am not the one to decide but if libmypaint were to update again its build system, it would be interesting to attempt a meson port (though really libmypaint is already so quick to build that I'm not sure at all if there would be any real advantage even here, apart for the sake of testing interesting-looking new technology) but I would not waste my time to port to CMake (at least, once again, in the current state of my knowledge and difference with autotools; for me both technology works OK in various environment).

[janisozaur]

Note: I am not a Windows user.

vcpkg (https://github.com/Microsoft/vcpkg) is a package manager that greatly eases the pain of building software on Windows, especially with MSVC. It can readily support CMake-based projects and in case when such support is properly written, adding a portfile is trivial.

The autotools-based projects I've seen included in vcpkg tend to get a CMake overlay added as part of vcpkg port.

In your appveyor.yml file you also use mingw rather than MSVC, I suppose there is a reason behind it as well.

vcpkg also seems to have support for meson.

[Jehan]

I am not a Windows user as well, though I regularly cross-build libmypaint for Windows, especially since we use libmypaint in GIMP. I timed it just now, just for the sake of it. From a clean directory, it took me 6 seconds (among which 3.7 secs in user CPU time) to configure + build fully libmypaint for Windows without any difficulty (I use crossroad to set up my win32 crossbuild environment).

I have a hard time imagining how any kind of build platform port would improve anything here (I mean, of course it could, but considering the time which would be spent in a port, the point is more weighing the advantages against the time spent to port).

But really you are not a Windows user, I am not as well. I think any decision based on "this Windows tool exists and I see in the docs it can use CMake" would just be unwise. If no Windows users ever asked for this, maybe this is just simply unneeded.

In any case, I won't be the one to make a CMake port. I did the autotools port, and have nothing against CMake (I also use this on a program I maintain), this is not the reason. Simply I don't see any need for it since autotools work just so well. Though I'm not sure that's the case here, such ports often feels to me more like time wasted on bike-shedding and church fights (CMake vs. autotools), which I personally don't care at all (as I said, I used both). :P

[janisozaur]

Having ported a bunch of stuff to emscripten/webassembly and then some more to UWP, based on my experience with autotools and cmake, I say the latter is vastly easier to integrate into whatever workflow you have and the barrier of entry is likewise lower.

Even though I'm not a Windows user, I found vcpkg to greatly reduce the pain of trying to develop anything on Windows, as it is able to provide required packages and make them available to MSVC.

I contributed to OpenToonz, a program using libmypaint, and based on how convenient vcpkg is, I would be interested to see all its required packages available through it, to remove the obstacles from would-be developers on Windows+MSVC.

[Jehan]

Anyway I leave open for the maintainer to see. I am not saying I am against in absolute. I only give my opinion on the topic (and also I say I won't do it, for sure; others can if the maintainer is OK with the idea).

[odysseywestra]

The reason we use mingw in the appveyor build system is it to be compatible with MyPaint's build process itself which uses mingw. Makes it easier for us to pack everything as one package and keep a Linux workflow on our alpha Windows builds.

On Fri, Dec 22, 2017, 4:49 AM Jehan notifications@github.com wrote:

Anyway I leave open for the maintainer to see. I am not saying I am against in absolute. I only give my opinion on the topic (and also I say I won't do it, for sure; others can if the maintainer is OK with the idea).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mypaint/libmypaint/issues/112#issuecomment-353592193, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwVsiVCz0C6akwNieUydloaAq1lGXzdks5tC6VCgaJpZM4RK7f5 .

[QuLogic]

I actually have a local attempt at building with Meson. I think the only major thing missing was OpenMP support, but it has been a long time since I've looked at it.

[jbicha]

meson is a lot cleaner build system than autotools.

For instance, libmypaint 1.3 will silently not build the docs if --enable-docs is set but all of the required build dependencies aren't available. I could file a separate bug for that issue but I'd rather encourage someone to spend their time implementing meson than getting autotools to work as intended.

There's no need to run ./autogen.sh and distribute all these generated files in your release tarballs which makes it easier to do releases from GitHub.

[QuLogic]

Here is a branch with a meson build. It is a straight conversion of the autotools stuff, so it can probably be simplified. I have not tested it with every option, and the pkgconfig substitution is incomplete (I'd rather use meson's pkgconfig generator.) There seem to be a few differences between the installed results, but I think some of them may be bugs in the autotools side. I probably won't investigate any further unless there is interest in this upstream.

[Salamandar]

@QuLogic I'd love to continue your work (did not read the code yet), do you accept if I do a PR with your commits ?

[QuLogic]

Sure, I suppose, go ahead.

[SleepProgger]

Just a heads up: Krita seem to build libmypaint using cmake ( https://github.com/KDE/krita/tree/master/3rdparty/ext_mypaint ). So IF someone still wants to support cmake directly in libmyPaint (for example for easier Qt project integration) thats probably a good place to peek into.

[Jehan]

We have someone at GIMP team (with full trust on code quality) who wants to port libmypaint build system to meson. I'm going to assume that the discussion here implies that the rest of the team would agree on such a port being done. So if he does it, I would review and merge.

Please if any other of the team wishes to make a veto vote, tell us before the work is done.

@jplloyd Any comment on your side?

[odysseywestra]

I'm down with switching over to meson for the build libmypaint. I would also make sure to update the ci tools on both this repo and MyPaint repo as well reflect the changes to we can test and deploy builds for windows and appimage as well.

Just let me know what you need from me and I'll do what I can.

[Jehan]

Right, CI scripts must be updated too. (← @nielsdg)

P.S.: by the way, if this happens, it will come with a port from deprecated intltools to full gettext, since it was the initial hurdle we had, as we just moved away from intltools in GIMP (and libmypaint is possibly the last dependency which still uses it). 😄