Appveyor - Windows autobuilds

[tmarrinan]

I created an appveyor yml file for autobuilding libepoxy on Windows and uploading the install artifacts (include, lib, bin) as a zip file to the GitHub releases. Currently the script turns EGL support off.
The appveyor yml file would have to be edited to upload to the main repo's GitHub page rather than mine (simply replace 'auth_token', with an encoded GitHub API token for appveyor.

[yaronct]

@tmarrinan: Thanx! Plz tell me when you're done with the commits :)

[tmarrinan]

Just finished - realized my script, while specifying an x86 and x64 platform, was having CMake generate x64 builds in both cases. I have now confirmed that it properly builds both 32 bit and 64 bit dlls for Windows.

[yaronct]

Well, we currently don't have an appveyor.yml file, and one prolly wouldn't hurt, and the one u want to merge seems essentially fine to me, so I don't mind merging it. I just still want to understand that authentication token thing again. Y is it needed at all? I mean, to run a build u just need access to the public stuff of this repo, don't u?

[tmarrinan]

To test the build, you are correct - no authentication needed.
The script I provided also uploads the 32-bit and 64-bit Windows builds (header files, .lib, and .dll) to GitHub as a release artifact. Therefore Windows users could just download the prebuilt binaries instead of needing to compile libepoxy on their own machine.
You can check the releases page of my fork to see the result.

[yaronct]

@tmarrinan: As I no longer have write access to this repo, you'll have to work it out with other ppl now, sorry.

[ebassi]

Thanks for your pull request.

Sadly, Epoxy does not support CMake any more, so I cannot merge your PR. We do support Meson, though, and I'm pretty sure it works on Appveyor, since Meson itself is tested that way on Windows.

Could you please modify this PR, or open a new one?

Thanks again for your contribution.

[tmarrinan]

Ok - The AppVeyor script now uses Meson to build libepoxy. I have not yet tested downloading the release artifacts on a Windows machine without libepoxy to ensure that they work out of the box. I should be able to get around to that tomorrow and confirm that all works as expected.

[ebassi]

@tmarrinan Thanks ever so much for working on this.

[tmarrinan]

Unfortunately, it didn't quite work.
I am packaging up the following files after doing an msbuild on libepoxy.sln:

• include
  • include\epoxy*.h
  • build\include\epoxy*.h
  • build\src\config.h
• bin
  • build\src\epoxy-0.dll
• lib
  • build\src\epoxy.lib

When CMake was used to build the project, libepoxy.sln had 2 steps - a build and an install. The install took care of grabbing all the needed build files and placing them in a specific directory. Is there an equivalent that I am missing in the Meson generated .sln?

[ebassi]

I'm more familiar with the Ninja backend for Meson, which has a ninja install step. I'm going to ask the Meson developers whether Meson generates an install rule with the Visual Studio backend as well.

[tmarrinan]

Even with ninja, I don't see how to set the install directory (typically referred to as 'prefix') for ninja install

[ebassi]

@tmarrinan Usually, you set the prefix with meson, e.g. meson --prefix=/some/path.

Additionally, if you want to add a different root for the prefix, e.g. use --prefix=/usr and then install in /some/other/root/usr, you can use DESTDIR=/some/other/root ninja install.

[nirbheek]

There's two relevant settings in Meson. One is the toolchain to use and the other is the backend to use. As you might expect, the former selects what compiler/linker will be used to build the project. The latter only selects what build-tool will be used (similar to cmake's backends).

The toolchain is auto-detected from the environment, so if you run vcvarsall.bat and then run Meson we will use MSVC (unless CC/CXX are manually set in the env). On Windows you can set the backend when you run meson to be either Ninja (with --backend=ninja) or MSBuild (with --backend=vs2015).

If you select ninja, you use it exactly like on Linux. ninja to build, ninja install, etc. If you pick vs2015, you run msbuild on the generated solution file (projectname.sln) to build, and there is no install target because the concept does not exist for MSBuild. Note that you can mix and match toolchains and backends. For instance, you can use the MSVC toolchain and Ninja. You can even use the MinGW toolchain and MSBuild.

The two backends are (supposed to be) identical in every way. The only advantage of the Visual Studio backend is that it generates project files and solutions, so you can open the project in Visual Studio and hack on it. In this case for CI, you should almost certainly use --backend=ninja for building with MSVC.

[tmarrinan]

Ok - I've updated the build script to use ninja, which nicely "installs" build artifacts to a specific directory. However, when I download the release and attempt to build an application that uses epoxy, I get a number of the following error:

error LNK2019: unresolved external symbol "__declspec(dllimport) unsigned char const * (__stdcall* epoxy_glGetString)(unsigned int)" (__imp_?epoxy_glGetString@@3P6GPBEI@ZA) referenced in function ...

[tmarrinan]

Nevermind - just realized that my test application is C++, but epoxy was built as a C library.
Adding extern "C" around the #include statements solved the issue!

[ebassi]

Stellar!

So, I'd say we can merge this. I'd prefer to squash all the commits and merge them. Is it okay for you, @tmarrinan?

[tmarrinan]

Sure!
I haven't really done that before, and am struggling a bit. A quick google search shows an interactive session, which is quite a pain since I'd be trying to squash hundreds of commits. Is there an easy one-liner to squash all commits since creating a fork?
I've tried git rebase -i {commit_id} where commit id is my first commit from my fork. Even when I painstakingly go through and squash all but the first line, it doesn't seem to work. I get the following message:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'
interactive rebase in progress; onto 72a7586
Last commands done (37 commands done):
   pick 61dac91 build: Clean up some Meson usage
   pick ced192c egl: Fix the query for the current context's API
Next commands to do (72 remaining commands):
   pick 80f20ce cross: Tweak inclusion path for Fedora/mingw64
   pick aef80bc build: Ensure that autogen exits with the right code
You are currently rebasing branch 'master' on '72a7586'.

nothing to commit, working tree clean
Could not apply ced192c30b8c1bcc9ad2d5dc3362395b7d2fab8b... egl: Fix the query for the current context's API

[ebassi]

No, worries @tmarrinan — I'll be happy to do that myself.

I'm not sure if I have the rights to get an API key for Appveyor, as I don't own the repository; I'll ask Eric if needed.

[ebassi]

Looks good; I've replaced the auth token for the deploy step with a token of my own.

[ebassi]

Again, thanks ever so much @tmarrinan for the patience and work.