Bug 105521

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.

Created attachment 138132 [details]
appveyor build log

Your configuration works out of the box :-)

(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.

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.

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).

(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/

(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\

(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 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 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

(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!

-- 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.