I’m trying to combine JUCE with Cocotron to make a windows x64 vst and an iphone app – from the same codebase apart from the GUI and interface.
Is it possible to compile the X64 (or x86 if need be) library from a Mac on x-code? I am trying to keep most of the code obj-c as iOS is the main target but the win vst is also indispensable.
Any thoughts on this approach would be greatly appreciated.
Not in this universe, I’m afraid!
I’m very new to all of this. I know that is what Cocotron is doing to make the windows dll’s from XCode, but I can’t figure out what else is able to follow suit.
How might you approach the problem instead?
Well, you have to have a PC anyway, to test your product… so compile it with that!
I’m sure there are ways you could somehow cobble together some kind of mingw-based solution that might run on OSX, but I wouldn’t trust it, and it’d be impossible to debug with.
Well, it may be possible. Xcode can use GCC, and it supports cross-compilation.
It’s not usual though - probably more trouble than it’s worth. You’d need to get a whole set of Mac-friendly windows headers and lots of other awfulness.
Easy to run a virtual machine and some windows tools for an occasional compilation.
I use Windows 7 x64 as my main machine so that’s not an issue. The x64 vst is so that I can do my composing work on my computer till I can get totally moved over to iOS over the next year of two.
I’m looking to use Cocotron, which is only available running on XCode, so that I have access to CoreData. I think their process does use GCC
So far the most difficult part of getting the project going is finding a good ORM for a SQLite database that is central to the app. I have not been able to find anything really decent for C++. Because my main concern is iOS I figure I can leverage the optimazations of Core Data there as long as the Windows vst version is able to get by.
I think the Cocotron project has thorough instructions to get the apps to compile, and I know they come with template xcode projects. From what I have read all of the feed back for Cocotron is unexpectedly positive. Is including JUCE into the process something that is going to break that process or is it just the process itself that you are wary of?
I have arrived at this approach after a long search for frameworks for Dependency Injection, ORM and and threading. Are some of these needs made unnecessary by JUCE itself?
I hadn’t heard of cocotron before. Isn’t it a bit risky to publish a framework whose whole purpose is to rip-off the design of an API that’s owned by one of the largest and most litigious companies in the world?
Well, we got threads!
2 years ago we had our building system entirely crossplatform. That means e.g. the Visual C++ optimizing compiler ran on wine and GCC was working as cross compiler for LInux. This worked pretty well.
We stopped using it in favour of separat building systems because:
- you are forced to actually use the other build before handing it to a tester
- you don’t need to write Makefiles by hand (yes we had Visual C++ GNU-Makefiles, not NMAKEfiles)
- you can get much easier updates for the perticular compiler chain (no wine tweaking etc.)
- switching compiler/linker switches is much easier
- You have a most recent SVN/GIT trunk while building ( I heard of people who forget to check in their code actually )