CMake and Makefiles build broken on Windows

[pierrejoye]

@nathanaeljones any appealing reason to have changed the Makefile for something we do not actually control? I would rather stick to the struture we had for cmake and PHP, using binaries/prebuilt deps that are validated and widely used. Any comment to do something different welcome :)

CMake as of now is also broken,

Using a simple command like:

cmake -G "Visual Studio 14 2015" -DBUILD_TEST=1 -DENABLE_PNG=1 -DENABLE_JPEG=1 -DENABLE_FREETYPE=1 -DENABLE_WEBP=1 -DCMAKE_LIBRARY_PATH=c:\php-sdk\master\vc14\x64\deps\lib -DCMAKE_INCLUDE_PATH=c:\php-sdk\master\vc14\x64\deps\include

Which simply requires to copy the deps llibs in ..\deps generates a clean build using all libraries we support. Deps prebuilt can be fetched here:

http://windows.php.net/downloads/php-sdk/

or can be built easily using:

https://github.com/winlibs

This is something I am not keen to change to some other structure or pre built binaries.

Thoughts and comments more than welcome.

[pierrejoye]

It also means we need to restore the cmake/modules directory as currently CMake on Windows is a big mess from a deps point of view.

Installing system wide builds files is an absolute no-go, especially when it comes to create clean and custom builds.

I have to check if we can have it used only for windows and keep using system ones for other platforms, if that helps.

[cmb69]

I would rather stick to the struture we had for cmake and PHP, using binaries/prebuilt deps that are validated and widely used.

+1

[vapier]

I think before we seriously consider supporting the Windows builds, we need to get the appveyor CI stuff working. I spent a little time on it, but I've never used it before, and it's been years since I built under Windows (majority of my work has been with mingw).

along those lines, should we look at adding mingw to Travis? or would it not be that useful as we expect the majority of people to build under Windows using an MS toolchain?

[pierrejoye]

I think before we seriously consider supporting the Windows builds,

We do. And we used to run tests but things went off on my side after latest 2.1. But we do support windows.

we need to get the appveyor CI stuff working. I spent a little time on it, but I've never used it before, and it's been years since I built under Windows (majority of my work has been with mingw).

All for it, back then it was not available/free to use for oss. So i am all for using it.

along those lines, should we look at adding mingw to Travis?

I think we can, it used to work.

or would it not be that useful as we expect the majority of people to build under Windows using an MS toolchain?

Both actually :)

[pierrejoye]

To be more precised, for windows, the priorities are:

1. Cmake
2. Nmake makefile (very very handy)
3. Mingw (not sure we can use std configure here or makefile

For both nnake and cmake I do want to keep supporting php pre built deps.as they are widely tested and supported.

[lilith]

It's been years, so I'm not sure what changes you're talking about. There were a couple scenarios we (Imazen) were facing:

1. Windows doesn't have shared libraries, and the prebuilt binaries for php had a lot of flaws we kept encountering. We needed the ability to update our dependencies immediately when sec updates happened.
2. Linux often ships with extremely outdated system libs.
3. Static compilation was often useful.

So having control over which git revision of every dependency turned out to be helpful. Thumbs.sh provided this, albeit in a less than perfect manner. I now use Conan.io instead of thumbs.sh for all of my projects, and can't reccomend it enough. It doesn't care about your build system; it just ensures all the dependencies are compiled and made available for your build target, whether you use makefiles, autotools, CMake, etc. Very convenient, especially for CI, where you may want to test using, say, a different libpng than is shipped with Travis default. Ofc, docker could also be used, if you're willing to maintain the container image.

It's also slightly easier to test against multiple versions of dependencies that way. And, if your deps are already on Conan.io, the investment is minimal.

Since Conan.io coexists with CMakeLists.txt and your makefile, there's no need to use it unless you want to control/fetch dependencies instead of using the system set.

[pierrejoye]

The main points are:

• Grab the deps and put them in libgd/../deps and it is all good for a build
• The winlibs are literally used by millions users and updated regulary
• It should still be possible to use any other deps src tho'. The default must however works out of the box

I will take a look (on my list) to conan.io. i was thinking about chocolaterey but the way it installs package is a bit aweful when it comes to dev files :)

[vapier]

i'm not saying Windows isn't supported. i'm saying before we embark on trying to get things building/working again, we get the CI running for these. otherwise we'll spend time fixing things now only to have them break again and not notice.

doing configure+mingw by itself isn't a problem. it's more how do we get the mingw toolchain in the Travis Ubuntu environment. i suspect it's not hard.

[rashadkm]

what about CMake ExternalProject to get dependencies before building libgd?

[pierrejoye]

@vapier ah ok :) And yes, totally agree.

CMake seems to need more love in the custom Find*, also some updates in them to support 3.x better.

In the meantime, I went for the easiest way, updated the makefile.vc, at least it builds now with most features. Tests suite will follow.

@rashadkm could be useful. I am not sure it is worth the extra work to maintain that. Given how easy it is to grab the deps, unzip in ..\deps, builds :)

[rashadkm]

@pierrejoye , agreed that it won't be as easy compared to just downloading dependencies into deps.
if winbuilds are able to give clean build, maintenance overhead will be less.

[pierrejoye]

I started to port gdtest. Only missing is the temporary directory. I may simply go for the system temp directory for the time being.

Alternatively I can port what I did in php for mkdtemp but :)