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