It looks like the mixxx-win32lib-msvc100 folder hasn’t been committed to this
branch yet:
http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/mixxx-buildserver/
Under trunk, all I see are these:
asmlib
mixxx
mixxx-win32lib-mingw
mixxx-win64lib-mingw
mixxx-win64lib-msvc
Is that new directory (along with SConscripts) in a state where you can check
it in?
From: Patrick Lang
Sent: Tuesday, January 18, 2011 10:57 AM
To: albe...@mixxx.org
Cc: mixxx-devel@lists.sourceforge.net
Subject: Re: [Mixxx-devel] Current state of Windows builds?
I'll try to take a look at that branch sometime this week.
Here's a few things to consider:
You can build X86 from an X64 VM without any issues.
I rarely build native X64 applications because there's little benefit to them.
I don't see why Mixxx would ever need to address > 3G of memory under normal
usage, and 64 bit arithmetic is available to 32 bit processes through SSE.
There are also issues with ASIO and X64 apps as well - some driver packages
only include a 32 bit ASIO DLL only. The only "real" 64 bit app I use
regularly is Reaper. I think the refactoring to handle multiple library
versions (x86/x64, debug/retail, msvc/mingw) is needed, but it might make sense
to focus on getting x86 working consistently first.
Do you happen to have a more specific depot location or link for the libmad/id3
sources? I did a bit of digging on launchpad, but wasn't sure which version
you were referring to for the latest patches.
> Date: Mon, 17 Jan 2011 18:34:52 -0800
> Subject: Re: [Mixxx-devel] Current state of Windows builds?
> From: albe...@mixxx.org
> To: patrick.l...@hotmail.com
> CC: mixxx-devel@lists.sourceforge.net
>
> 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
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
