Newest Jucer Juce projects - Mac & iPhone clash


#1

The Mac and iPhone static libs seem to build to the same place and same names, with hilarious results.

Bruce


#2

That was the case even in the old juce projects, though, wasn’t it?


#3

I don’t know! That didn’t occur to me, since they were in the same project.

Nonetheless, should they be, for instance, named differently, so both can be used and/or it’s not awful to switch between the two? Am I the only one still using static libs?

Bruce


#4

You could also try creating a separate folder(output directory) for iPhone and the Mac OS libraries.


#5

I did a different name for the libraries, but the juce project will override that next time I get the head.

I was just saying, I think it’s reasonable to assume that people will be working on iphone/ipad and mac projects at the same time.

Bruce


#6

I know, Jules will have to make the changes. He can either rename the libraries or create different output directories. My vote would go for changing the library name.


#7

Of course it’s broader than this, - iPhone development needs two libs, one for the device and one for the simulator. I’ve found it easier to just use the build-from-source versions of the new Jucer rather than static libs. I tried a while ago to build all the Mac and iPhone libs and ‘lipo’ them into ‘debug’ and ‘release’ static libs but of course the iPhone simulator and the Mac UB libs both contain i386 binaries so that wouldn’t work.


#8

I’d go for putting the each static library into the Builds subfolder that names the platform for which the library has been built.
I’d do the same for Windows and Linux as well, for a quite complicated reason, but which would turn out to be very useful to me: I usually develop on Mac, but use Parallels Desktop to run a Linux virtual machine on which I compile the same project I develop on Mac, directly from the very same filesystem location thanks to Parallels Shared Folders that allow me to see from the Linux VM the content of the Mac disk. The result is that when I try to compile the project on Linux, it does fail on the first attempt because the Mac static library is in the same place and has the same name of the expected Linux static library, which in turn does not get compiled from the Makefile because the .a looks like up to date to it…

Long story short: putting each static library within its Builds subdirectory results in a much clearer understanding of what library has been compiled for what platform, and this probably adds more information to the whole development process.


#9

Thanks for the suggestions, folks.

I also like the idea of putting the static libs in their build folders. In the past I’ve avoided that because it means setting up library search paths for each project, rather than just having one global search path, but as the jucer can generate those paths now, that’s less of a problem.