Bug 105521 - Do CI builds on MSVC using Appveyor or similar
Summary: Do CI builds on MSVC using Appveyor or similar
Status: RESOLVED MOVED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: git master
Hardware: All Windows (All)
: low enhancement
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
URL:
Whiteboard: review?
Keywords: patch
Depends on:
Blocks:
 
Reported: 2018-03-15 13:46 UTC by Simon McVittie
Modified: 2018-10-12 21:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
cmake: Fold GObject detection into GLib detection (5.31 KB, patch)
2018-03-15 13:49 UTC, Simon McVittie
Details | Splinter Review
appveyor build log (482.83 KB, text/plain)
2018-03-15 15:24 UTC, Ralf Habacker
Details
Add Appveyor build configuration to test MSVC builds (3.04 KB, patch)
2018-03-15 19:22 UTC, Simon McVittie
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Simon McVittie 2018-03-15 13:46:41 UTC
We regularly test that dbus builds successfully as a native build on Linux, and as a cross-compiled mingw64 build for Windows, by pointing Travis-CI to dbus' semi-official Github mirror. We don't do the same for MSVC builds, which makes it hard to be confident that we haven't broken them.

Appveyor seems to be a Windows equivalent of Travis-CI. I've tried to set up a build there for dbus, but so far it isn't working.

Work in progress (probably doesn't work yet): https://github.com/smcv/dbus/commits/appveyor

I don't really know what I'm doing (I've never set up an Appveyor build before) and trial-and-error is rather slower than on Travis-CI, so if someone has used it before, I'd appreciate a fixed version of the build.
Comment 1 Simon McVittie 2018-03-15 13:49:45 UTC
Created attachment 138131 [details] [review]
cmake: Fold GObject detection into GLib detection

Everywhere that we want GLib, we also want GObject and GIO. Detecting
GLib and GIO but not GObject makes very little sense anyway, because
GIO depends on GObject.

---

This build simplification might help the Windows build to succeed without necessarily needing pkg-config.
Comment 2 Ralf Habacker 2018-03-15 15:24:56 UTC
Created attachment 138132 [details]
appveyor build log

Your configuration works out of the box :-)
Comment 3 Simon McVittie 2018-03-15 16:27:07 UTC
(In reply to Ralf Habacker from comment #2)
> Your configuration works out of the box :-)

Only on x64. I'm trying a new version that might work on 32-bit too.
Comment 4 Simon McVittie 2018-03-15 19:22:00 UTC
Created attachment 138145 [details] [review]
Add Appveyor build configuration to test MSVC builds

---

I'm not happy with the performance of this build (4 builds x 23 minutes!) - but it does seem to work, and gives us a smoke-test for whether dbus still compiles on MSVC.

I had hoped that vcpkg packages would be cached between builds, but I tried pushing a trivial change to the same branch to see what happens, and it seems to be starting at the beginning of configuring expat again. Please could some who knows about Windows look into that?

I'm certainly not going to add any more entries to the build matrix (like MSVC 15) unless we can make it faster.
Comment 5 Simon McVittie 2018-03-15 19:24:28 UTC
I've created a "dbus" user on Appveyor, linked to a new @dbus-ci user on Github, so that we can have builds from the semi-official Github mirror in the same way we do for Travis-CI. After appveyor.yml is merged, individual dbus contributors can also register their personal Github accounts with Appveyor to get their branches tested (again, like I do for Travis-CI for my own contributions).
Comment 6 Ralf Habacker 2018-03-15 20:05:49 UTC
(In reply to Simon McVittie from comment #4)
> Created attachment 138145 [details] [review] [review]
> Add Appveyor build configuration to test MSVC builds
> 
> ---
> 
> I'm not happy with the performance of this build (4 builds x 23 minutes!) -
> but it does seem to work, and gives us a smoke-test for whether dbus still
> compiles on MSVC.
this is nice :-)
> I had hoped that vcpkg packages would be cached between builds, but I tried
> pushing a trivial change to the same branch to see what happens, and it
> seems to be starting at the beginning of configuring expat again. Please
> could some who knows about Windows look into that?
> 

It looks that build cache support is what you want, see https://www.appveyor.com/docs/build-cache/
Comment 7 Ralf Habacker 2018-03-15 20:12:20 UTC
(In reply to Ralf Habacker from comment #6)

> > I had hoped that vcpkg packages would be cached between builds, but I tried
> > pushing a trivial change to the same branch to see what happens, and it
> > seems to be starting at the beginning of configuring expat again. Please
> > could some who knows about Windows look into that?
> > 
> 
> It looks that build cache support is what you want, see
> https://www.appveyor.com/docs/build-cache/

see https://www.appveyor.com/docs/lang/cpp/#cache-installed-packages

Cache installed packages - To enable faster (cached) rebuilds add the following to the cache section in the appveyor.yml:

  cache: c:\tools\vcpkg\installed\
Comment 8 Simon McVittie 2018-03-15 20:54:45 UTC
(In reply to Ralf Habacker from comment #7)
> see https://www.appveyor.com/docs/lang/cpp/#cache-installed-packages
> 
> Cache installed packages - To enable faster (cached) rebuilds add the
> following to the cache section in the appveyor.yml:
> 
>   cache: c:\tools\vcpkg\installed\

That's what I did (with a cache-breaking flag file so we can clear the cache if we need to), but it doesn't seem to be helping.
Comment 9 Ralf Habacker 2018-03-16 19:11:08 UTC
Comment on attachment 138131 [details] [review]
cmake: Fold GObject detection into GLib detection

Review of attachment 138131 [details] [review]:
-----------------------------------------------------------------

This simplifies the glib stuff, thanks - looks good
Comment 10 Simon McVittie 2018-03-19 12:34:45 UTC
Comment on attachment 138131 [details] [review]
cmake: Fold GObject detection into GLib detection

(In reply to Ralf Habacker from comment #9)
> Comment on attachment 138131 [details] [review]
> cmake: Fold GObject detection into GLib detection
> 
> This simplifies the glib stuff, thanks - looks good

Merged, thanks
Comment 11 Simon McVittie 2018-03-19 12:38:29 UTC
(In reply to Simon McVittie from comment #4)
> Created attachment 138145 [details] [review]
> Add Appveyor build configuration to test MSVC builds

Any thoughts on this? The performance is pretty bad, but having a systematic way to prove that we can compile on at least one version of MSVC is better than nothing.

If someone can get the cache to work, that would mitigate the performance issues. I'm probably not going to work on that myself any time soon, but others are welcome to improve my patch.

Perhaps building 32-bit release and 64-bit debug, or similar (but not the other pairings) would help too; or perhaps we could do one build with msbuild (to prove we can) and the rest with ninja, if ninja is faster?

Or does something like ccache exist on Windows?

I'd like to try builds on more than one MSVC version, but not until they're a lot faster!
Comment 12 GitLab Migration User 2018-10-12 21:32:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/200.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.