Linux makefile on OSX?


#1

Pardon my ignorance but how much work would be involved in getting a makefile created with the introjucer to build a project on OSX? I usually run xcodebuild from the command line but the builds take forever. I’m wondering if a simple makefile would be faster. I know it’s still going to use the same compiler but I would like to at least see if I can speed up build times at all, even a small decrease would be most welcome.


#2

I would support this as well. The memory usage of Xcode is very high, especially during the compilation of the amalgamated files.

Ideally, JUCE could be built as a number of .dylib and .a binaries corresponding to each JUCE module. The libraries could then be linked to whatever application you’re building instead of be compiled each time. Boost and SFML do this, and the result is very convenient. This would free us from building on bloated IDEs.


#3

Yes… that’s why I ditched them a long time ago. Xcode can build the current version in just a few seconds thanks to the module structure. Attempting to use libs would be slower, less flexible, and far more complicated to manage.


#4

I’m probably going to ditch the amalgamated version of JUCE as well.


#5

What do you mean by “slower”? Surely, compiling + linking can’t be any faster than just linking. Or do you mean slower to set up builds? I would say that in an environment with a good package manager (Linux, Mac OS X with Fink or Homebrew, and MAYBE Windows with Chocolatey or something) would be much easier to manage cleaner cross platform build systems. And since code speaks 1000 [size=50]64-bit[/size] words…

[code]# brew install juce

g++ -ljuce -L/usr/local/include …

[/code]

MyProcessor.cpp

#include <juce/audio_processors/audio_processors.hpp>
#include ...

However, without a universal method of easily distributing binaries to different platforms, I would agree that the build for projects using JUCE would be more complex. Unless boilerplate code with flexible build scripts would be provided to accommodate the change.


#6

To use the modules involves popping a few cpp files into your project and building. No messing about with package managers, or makefiles, or different projects on different OSes, or any of that tedious crap. To build the entire set of juce modules on my laptop takes about 10-20 seconds, and obviously that’s only necessary when you’re doing a clean build.

So by going to the enormous hassle of building a dozen separate libraries on 2-3 different OSes using different build tools, and maintaining different versions of those libraries for all your different apps (assuming your apps use different configs) will end up saving you a few seconds each time you do a clean rebuild.

There’s just no contest IMHO. I’ve seen and used a lot of build systems over the years, and come to the conclusion that the best build system is NO build system at all, just use the raw cpp files. If I could make the library headers-only, I would!


#7

As much as I enjoy the banter back and forth between users, I’m still at a lose as to whether it would be relatively straightforward to get a Juce linux make file working on OSX? I know very little of OSX, does it use similar library/linking conventions to Linux, or are they quite different?


#8

Re: linux makefiles, don’t waste your time. Even if it was straightforward (and it probably isn’t), there’s no reason to think it’d be any safter than letting xcode run the build. Either way, the same compiler would get called a bunch of times, and that’s what takes the time.

Ways to speed up your build: Use modules. Use LLVM. Restructure your files.


#9

Thanks Jules. That’s all I needed to hear.


#10

I said it already but it’s worth repeating.

The “unity build” source file organization style (i.e. how JUCE modules are structured) and abandonment of static libraries, is a significant step forward in the evolution of coding style. Doing away with setting preprocessor options (for static libs) in the IDE / Makefile settings is a relief.

Not having to make individual header files stand alone (#include this, #include that), and having all of the #include dependencies listed exactly once (in the module source and/or header) is great. Being able to see at a glance what #include dependencies a module has is very useful.

Plus, the build times are much faster. Especially if your project has a number of modules equal to or less than the number of cores on your system.

Why people want to use CMake, M4, autoconf, autotools, or any of the myriad of bulky, hard to use systems for building is beyond me.

I’d also note that whenever I expose the mainstream C or C++ community to these ideas they are always met with ridicule. Fuck them.


#11

Sorry, most of this is above my head. Does this mean we must use Visual Studio or Xcode?

My preference to use libraries is because I know how to use them. Regardless of whether the module approach is better, is its usage documented somewhere?