Hi folks,
*tl;dr:* please contribute to the Windows build repository.
<https://github.com/mixxxdj/buildserver/tree/2.1.x-windows> Automatic PR
building by Jenkins and/or Appveyor is on the way. Please file and fix
issues <https://github.com/mixxxdj/buildserver/issues> -- if
build_environment.bat doesn't work out of the box on your machine with
VS2015 then that is a bug!
After the great work by Sean, Josep, and Sebastien at getting our Windows
plumbing in much better shape and moving us to VS2015, I've done some
re-organizing of our buildserver repo.
* The branch layout for the buildserver repo is now named after Mixxx
releases (there is no more "master" or "windows_environment" branch).
- 2.0.x-windows -> Windows dependencies for 2.0.x
- 2.0.x-unix -> Linux and Mac dependencies for 2.0.x
- 2.1.x-windows -> Windows dependencies ...
- 2.1.x-unix -> Linux and Mac dependencies ...
I also went back and tagged the commits used to create release environments
for 2.0.0 with 2.0.0-windows and 2.0.0-unix.
* I added a Jenkins job that builds the Windows environment for each
architecture/release-type whenever a commit is pushed and uploads a
"minimal" (just the libraries, includes, binaries, PDBs, and logs -- no
object files) to downloads.mixxx.org
https://builds.renegadetech.mixxx.org/job/buildserver-2.1.x-windows/
http://downloads.mixxx.org/builds/buildserver/2.1.x-windows/
* I am going to set up PR builds against the buildserver repo so that
anyone can send a PR and see if it builds successfully.
* AppVeyor builds download a zip of dependencies from downloads.mixxx.org
<http://downloads.mixxx.org/builds/appveyor/environments/2.1/>. This model
is really nice, since everyone has visibility into exactly what the build
environment is (it's tagged with a git sha, you can download it and look at
it, etc. -- and we could sign / fingerprint the zip), and there is no
"state" to the build -- no server environment to prepare other than
installing some tools and no possibility for someone to apply a fix to the
builder VM only without checking it in.
We should move to this model for Windows Jenkins builds. No more building
an environment on the VM itself (other than via a jenkins job of course) --
instead, we download the latest commit build of the buildserver
2.1.x-windows branch from downloads.mixxx.org and use that as the winlib.
The latest green Mixxx builds from Jenkins were built this way -- I
manually downloaded the latest winlib build from downloads.mixxx.org and
used that instead of building the environment manually on the VM.
* From past experience, one thing that stalls Mixxx feature development is
adding library support for Windows or Mac (e.g. LV2 support on Windows via
lilv). This usually bottlenecks on one of the people who has access to the
build VMs to add support. This is unfair to the feature developers because
it stalls them and unfair to build VM maintainers because it's a
requirement on their time that they often didn't plan for. This situation
stinks! I'm hopeful that we can now add library support via pull requests
-- now the feature developer who needs the library support can add it
themselves via PR and get feedback about whether it builds or not.
Alternatively, the feature developer can file an issue
<https://github.com/mixxxdj/buildserver/issues> in the buildserver repo and
some other kind contributor will take up the task and send a PR. The
maintainers can code review as normal and don't have to do much other than
hit the merge button. Bottleneck removed!
Sound good?
RJ
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
