Appveyor configuration for a Visual Studio 2015 build #64
Conversation
- Required adding a property sheet to pass C defines from the command line - Builds with libusb-win32 and libusbK - Builds 4 different permutations currently (x86, x64 /w Debug, Release) - Support for pushing tagged releases (only Release/Win32 currently) to GitHub Releases Notes: - Appveyor also has Cygwin available so it's likely possible to setup some Cygwin builds as well
|
Thanks!
Makes sense. No issue there.
Very nice! 😃
That's great. But I think I'll want to add MinGW and MinGW-w64 builds, since this is what I use to produce the actual releases of Zadig for instance. I've done something like this for Rufus very recently, so hopefully that won't be too difficult. I'll probably add that later, after I've integrated your proposal.
This is the only item I have a small issue with. I cannot see myself releasing an application that requires elevation without it being digitally signed (which of course, is not something that can be automated, as it would require AppVeyor to have the private key for my signing cert). So pushing something like the Zadig executable built by AppVeyor for user consumption is a big NO_NO. It's not that I don't trust the AppVeyor servers, but you have to consider that, as soon as there exists an unsigned version of Zadig x.y.z in the open, anybody can create a malicious version that can pass as Zadig x.y.z, and if users fall into the habit of downloading and running unsigned versions, because they are officially published as artefacts, it will end up putting users at risk. An app or library that installs drivers, and that you didn't build yourself, should always have a digital signature to validate its author. If it doesn't, you should not run it. And I understand that it's possible to use artifacts to push code archives, but I think any developer who wants the latest source will be familiar enough with git already, so I don't see the need to create source archive for each commit.
I've deliberately dropped compatibility for Cygwin in libwdi a long time ago. It was just too much work to ensure the code was Cygwin compatible (From various projects, I found that Cygwin was always a lot more work compared to MinGW, and that if there's a chance for anything to break, it'll usually be Cygwin). At any rate, thank you very much for this pull request. It looks fine for integration (I'll apply the changes I mentioned myself -- no need to do that, unless you really want to), and, just to give you an ETA, I think I'll be applying it within a week or so. |
|
Cool! Feel free to pull-out anything. Part of this was to experiment with the GitHub Release system which I've never used before. |
|
Mmm, unfortunately, the SourceForge download services is really hit and miss, which means we get build failures simply because the SourceForge mirrors refuse to server downloadable content. This already happened for 2 builds... 😞 I'd have to have to create my own mirror of the libusbK and libusb-win32 files just so that AppVeyor can pass... |
|
Yeah...I've noticed that as well. On the plus side, you can be sure that the binary doesn't magically change on you. |
Please avoid leaving these kind of details out. If you know something may not work in a patch you're proposing, at least mention it, instead of leaving it for the committer to find it and address. Since I have no time for dealing with all of SourceForge's bullshit (I moved my projects out of SF a long time ago, and never looked back), I have now placed the files on my own server. |
Notes: