Hi Patrick, On Sun, Jan 16, 2011 at 7:55 PM, Patrick Lang <patrick.l...@hotmail.com> wrote: > I just started using Mixxx 1.8.2, and am quite impressed with the state of > it. It’s simple and to the point, and I feel that the software gets out of > the way and lets me focus on the music. It’s almost like having a pair of > Pioneer CDJ’s and a mixer all in one without the extra stuff I don’t need in > Deckadance or Traktor. >
Thanks for the kind words! > I filed a midi mapping bug (with fix attached) yesterday, but haven’t gone > through setting up a full build environment yet. I have been DJ’ing on and > off since 2002, and am a software developer & tester by trade. I spent > years working on Linux and the *BSD’s, but focus primarily on Windows now. > Before I get started on my own builds, I was curious about the state of the > wiki page and some other background info on the builds. > (http://www.mixxx.org/wiki/doku.php/compiling_on_windows) Thanks for the MIDI mapping patch too. We should definitely look at that and apply it before 1.9 is out. > > First off, why is Visual Studio required? I build many large projects using > make or build.exe, which ship with the Windows SDK itself. I’m planning to > give it a try without Visual Studio, but I’m curious if this has already > been discussed. Good observation - I only realized that Visual Studio isn't required (just the Windows/Platform SDK) within the last few weeks when I was working on the build server. You can indeed build Mixxx without it, as the C++ compiler is part of the Windows 7 SDK. Visual C++ is a nice IDE though if you're doing development though. > > Are there any benefits to using Qt Creator over VS build? In general, I > have found that Microsoft’s VC++ compiler generates tighter code than GCC & > MinGW. Right now, the "official" way to build Mixxx is with the Microsoft compiler on Windows. Qt Creator and MinGW were side-projects which are not under active work at the moment. We periodically have a debate about whether we should be cross-compiling Windows builds using MinGW, but I disagree with this on the grounds that we should be using Microsoft's tools and compiler for Microsoft's operating system, otherwise you know we're signing up for lots of quirks. I've also heard many other people echo your sentiment that the Microsoft compiler is fast. That said, if someone wanted to spend their time on playing with MinGW, I wouldn't stop them, but personally I think it's a waste of time. Re: Qt Creator - I've never used it myself but it's supposed to be a decent IDE. Garth even had some cool builds of Mixxx for Windows cooked up using MinGW where GDB was bundled in, so you could get backtraces really easily from users. > > Is there any reason why the Vista SDK is recommended? The latest shipping > SDK (7.1) will build apps that work all the way back to Windows 2000. Agreed, I built with the Windows 7 SDK for the build server a few weeks ago with no problems. We should always try to be sticking with the latest SDK version, and if something doesn't work right, we should fix it. Please feel free to edit the wiki page, updating the documentation would be a great help. > > On a related note – what OS & service packs of Windows are supported? We support back to Windows XP, but I'm not sure if there's a service pack revision required or not. I've found that audio performance is significantly better on Vista and Windows 7 though. We bundle the Microsoft Visual C++ runtime DLLs inside the Mixxx installer (along with the manifest file if required), otherwise Mixxx won't run on XP. > > Anyway, if time holds out, I’m hoping I can contribute some developer builds > and bugfixes. I have a dedicated Hyper-V server at home with resources > available, and an MSDN subscription to get access to any OS version I need. > I recently saw the discussion on keeping a build VM available, but there may > be an easier solution. It’s possible to install OpenSSH on Windows using > either Cygwin or Services for Unix. If a few specific developers need > regular access to a Windows build system – OpenSSH may be sufficient. Thanks for offering your resources Patrick. We should have plenty of CPU power available once we have the server assembled, but that's very generous of you to offer your CPU time. :) RJ is currently assembling our beast of a build server, and I started working on the software side of it over Christmas a few weeks ago. I set up a Windows 7 virtual machine inside VirtualBox along with the Windows 7 SDK. The VM has a working build environment and has OpenSSH installed and working. (Getting OpenSSH going was not as easy I was expecting.) On the build server, we'll probably be running Ubuntu, and we'll be executing remote builds through the VMs. I've written a small Python script that reads in configuration files for each VM, then takes a list of branches and produces builds of each branch on each VM. Right now, I've only got the 32-bit Windows 7 VM set up but the script works. :) Anyways, there's two more things we could use your help with: 1) As part of the build server refactoring, I've started ripping those mixxx-winlib-blah folders out of our repository. I pushed the set of libraries I'm using on the build server to it's own repository here: https://code.launchpad.net/~mixxxdevelopers/mixxx/mixxx-win32lib-msvc100 It occurs to me that I've already screwed this up a bit, which is another reason why I need your help. I've probably mixed debug and release DLLs in that repository (most of them the ones that were in mixxx-winlib to begin with, with the exception of libmad and libid3tag which needed to be recompiled for the newer MSVC++ runtime). We need separate "Debug" and "Release" builds of all the DLLs to be in the repo, then we can fix our SConscript to pull libraries from the corresponding directory. If you want to do some hacking on the build system to help with this, making a branch off of the mixxx-buildserver branch would be a good way to start: https://code.launchpad.net/~mixxxdevelopers/mixxx/mixxx-buildserver (That's where I put some tweaks I had to do to make the automated builds work. I'll merge that into trunk once we get the build server up.) 2) 64-bit - I've completely neglected 64-bit stuff. We're going to need 64-bit builds of all those libraries too and a 64-bit Windows 7 VM set up. If you feel like setting up a 64-bit Windows 7 VM on our build server once we have it assembled, that would be very helpful. If you have a better idea for how we should be organizing our Windows builds too, I'm all ears. Anyways, I hope this gives you a good overall picture of the situation with Windows builds at the moment. We need to do some reorganizing but we could definitely use your help as it's moving very slowly at the moment. If you have any more questions, don't hesitate to ask! Thanks! Albert ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
