Site navigation

Trying to compile juce app using makefiles rather than xcode

MacOSX and iOS
#1

Background: I’m trying to port my app to mac[1], and one of the 3rd party libraries I use is giving me a massive headache in xcode. Given that I don’t need xcode’s IDE stuff as I primarily develop in MSVC, and I already have infrastructure in place to synchronize my make files for my linux builds, I’m quite happy to ditch xcode and work entirely with makefiles on the mac.

To get a feel for what I’m doing (I’m a total osx newb) I’m trying to make a lua premake for the juce demo. At this point I’m running into two problems that googling hasn’t resolved:

  1. what should I have in my package list? I’m not sure how the macosx packages translate:

Currently I have:

“carbon”, “freetype”, “pthread”, “rt”, “CoreAudio”, “CoreMIDI”, “GL”, “GLU”,
“juce”

which is most likely gibberish, as well as incomplete.

  1. when compiling I get :
==== Building JuceDemo ====
AudioDemo.cpp
/var/tmp//cc1o9QVq.s:486:invalid character '(' in mnemonic
/var/tmp//cc1o9QVq.s:516:invalid character '%' in mnemonic
make[1]: *** [build/intermediate/Debug/AudioDemo.o] Error 1
make: *** [JuceDemo] Error 2

I’m guessing that I’m missing something in my includes. I currently have

“/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/FlatCarbon”

in addition to the standard /usr/include

Can any Mac gurus point me in the right direction?

[1] obRMS: My boss just bought me a shiny new mac, and I now have three flavours of linux, WinXP, and Win2k all installed under parallels[2]. Extremely cool! I wish I’d made the jump ages ago!

[2] Rather amazingly I can get away with WinXP, and Mandriva2007 running simultaneously inside MacOSX without significant loss in performance on any OS.

#2

ooh, makefiles… I’ve never tried that on the mac. Is there perhaps a way to make xcode chuck out a makefile, and see what’s in there? Thing is, you tend to work with packages rather than bare libs, so xcode takes care of all the internal linking.

You can automate xcode’s build process though, so would it be easier just to use an xcode project but build it from the command line?

#3

turns out I can get my other library to compile inside xcode.

The problem actually was that Apple define verify as a macro[1]. This was causing all kinds of insanity when compiling, non of which helpfully pointed towards the issue that verify() is a public method in dcmtk, and which was f. Lua was equally unhappy when it encountered a check macro too.

[1] why in the name of god would anyone use the name “verify” in an OS level macro? Pretty much guaranteed to f-ck with just about every library out there, surely?

#4

Xcode won’t generate it, but there is another app, pbtomake, out there that does it. I would have made you one for the demo, but it’s really fussy about paths. You can fix up an Xcode project’s path types and generate one quite quickly, as I recall.

Bruce

#5

that’s cool to know!

I might still go the makefile path if I can, simply cos I’m not loving xcode, and I already have the make framework in place from my linux builds.

cheers. :slight_smile:

#6