Cannot Build Cubeb with Visual Studio about cubeb

[ahicks92]

Other things that appear not to be included include cubeb_resampler. Should I be going off the Mozilla version? Is there a difference?

[kinetiknz]

A CMake build backend would be nice to have, thanks for working on it.

It looks like we forgot to import cubeb_resampler.h from the Mozilla version. Grabbing it from there is fine. Unfortunately the development happens in both places, with manual resyncs, so things are forgotten from time to time.

[ahicks92]

So this is actually more complicated than I thought, and I'm kind of upgrading this issue to "doesn't currently build on windows, at all". Do we have anyone building this outside the Mozilla tree? I think it's working their because they seem to be wrapping it into a different build system; I'd ideally like to get the question as to whether I'm being temporarily idiotic about this either completely on or completely off the table as soon as possible.
The short version is this:

• Cygwin: requires removing some Microsoftisms, most notably _createthreadex. Does not support _aligned_alloc, but at least the MME backend needs it. Options for getting it working here seem to be implementing our own _aligned_malloc; Cygwin doesn't provide one, but maybe macro magic...
• MinGW: Does not understand the functions to run the sanity test properly, namely VerSetConditionMask or the macro (which windows redefines to the function). After some minor MinGW-related code edits, all source compiled; MinGW ultimately failed because, for whatever reason, Autoconf is forcing pthread, even if I edit it out of makefile.am.
• Visual Studio: On account that it's in Mozilla, it builds there with no source changes. On account that everything I've already said, this repository doesn't.

It would also be nice, for all three of these, if we could kill cubeb-stdint.h. I believe that all modern compilers support the regular stdint.h. How far back does compiler support need to go? For build systems outside autoconf, making our ow is not the easiest proposition. It may be possible to hack something with cmake; I've not gotten far enough to try. I want a windows build, any windows build at all, before I do that part of this.
And finally, the speex macros can be brought inside the cubeb-speex-resampler.h file, removing them from our build system. There is no reason I can think of that we don't just always compile it in and let dead code elimination take care of it later. Also, this is another thing that the autoconf stuff didn't set right for me on any of them.

[kinetiknz]

I merged #44, thanks for that. It hasn't been built from this on Windows by me for quite some time (only within Firefox), so it's not too surprising that there's breakage, sorry about that. Yeah, it uses a different build system within Firefox, and a decent proportion of the new changes happen there first and are resynced to this tree by me when I have a free moment. Not ideal!

It'd be nice to have MinGW and Visual Studio working, and I use them a bit, so I can assist with fixing it and keeping it working once the initial work is done. How important do you think Cygwin support is?

With the speex resampler, the idea is that cubeb supports building both in-tree and out-of-tree, and Firefox specifically uses the out-of-tree support because there's a locally maintained copy of the speex resampler in the Firefox tree already. We can do whatever makes life easiest, so long as we retain the ability for Firefox to use an out-of-tree speex resampler. I'm not too concerned about retaining that for the standalone cubeb build if it makes life more difficult.

[ahicks92]

I don't personally think Cygwin is important, but someone might. It was mostly something I'm doing for completion.
I have a working Windows CMake backend. It also mostly works on Linux; the one issue that is left is something I know how to fix. I'm going to set up to test it against OS X this weekend; I need a few hours to set up VMWare Fusion, and classes do not leave time for this.
I managed to retain the ability to use an out-of-tree Speex in both CMake and Autoconf. I've also figured out that CMake can, in fact, write files. Consequently, cubeb-stdint.h.vs is ultimately unnecessary. Unfortunately, I do not know how to generate it, so it's just including stdint.h. I don't think this is important: most compilers support C++11 nowadays, and I doubt that anyone is going to want to run CMake against an ancient one. In the event that they do, I'll work on it as necessary; I'm betting on Cubeb as of now over everyone else for my own commercial project, so its usability is something of concern to me. If worst comes to worst, you can do very creative things with asking CMake to compile source code and look at the output; I highly doubt it will come to that, however.

[padenot]

@camlorn, does the cmake branch on your fork contains all the work you've done porting cubeb to CMake ? I'm going to do a significant amount of work on cubeb at the beginning of next year, and I believe CMake would make that easier. If it is not finished, I can certainly continue where you left off.

[ahicks92]

yes. It contains all my work, but it's not quite finished. I had it working to some extent but ultimately just decided I needed to write my own backends. Fixing Cubeb was taking too long, and writing Winmm and OpenAL took like a day total because I had to write half the framework for it anyway. As I recall, it works at least on Visual Studio and maybe on Linux. But I never even started OS X.

[padenot]

We can now close this, the CMake backend has been merged and it works nicely with visual studio.