Feature makefile refactoring + osx working (almost)

[arturoc]

this moves the common parts of the different linux config.make files to a common file. probably needs a different organization but by now we have the the common parts identified

also osx is working, but still needs the bundle creation phase or at least use install-name-tool to tell the exe where the dynamic library for fmod is

[arturoc]

btw, i've only tested with xcode 3, so sdk 10.6 but should work with other sdk's too

[bakercp]

Exciting. I'll test it out.

[arturoc]

with that last commit the executable works, still no bundle but i think it's just a matter of creating a plist and moving the executable and libraries into an folder with the name of the project + .app

i've added an afterplatform step in the osx config, the bundle creation should go there

[bilderbuchi]

are those all those additions in export/osx/Frameworks/GLUT.framework/ intended, or did something slip in sideways?

[arturoc]

@bilderbuchi yes that's correct

btw, don't merge this yet, there's a problem with the dependencies on the OF project i'm correcting it + adding android support

[arturoc]

ok, so with that it works on all platforms we are just missing the bundle creation in osx, going to take a look but it should be easy.

@bakercp i'm thinking on merging the makefiles on develop soon, it's working perfectly on all platforms now and i keep having to add things in the main repo, mostly for android so it would be good to have to maintain only one version.

i was thinking on copying/removing the needed files in develop, and then merging develop back here, but if you have any other idea?

[arturoc]

this is ready to merge, what it does now:

• refactored linux common parts to makefileCommon/config.linux.common.make
• optionally uses ofx*/addon.make for addon config, every variable inside the file is optional too, there's an example in ofxOpenCV
• osx working with bundle creation (tested in xcode 3 and 4 but might be good to test with latest xcode)
• make run target to make it easy to run projects from text editors (tested with gedit in linux and sublime in osx)
• android working
• addons obj in common folder inside addons/obj/ofx*/platform makes compiling way faster mostly in platforms with addon like raspberry or android since you need to compile the common addon only once, will also reduce the space in disk a lot

[bilderbuchi]

will you still make the changes we talked about over in https://github.com/benben/ofxAddonTemplate/issues/4 ?

make run target to make it easy to run projects from text editors (tested with gedit in linux and sublime in osx)

I'm curious, what do you mean? what is your workflow here (with gedit)? didn't this already work before with the console within gedit (i.e. calling make), or is there some smoother workflow with some gedit plugin?

addons obj in common folder inside addons/obj/ofx*/platform

I think it would be better if that obj folder would be within the addon folder, i.e. addons/ofx*/obj/platform, no? that way all addon data stays together, compartmentalized in the addon folder, and it seems like a more logical location when dealing with addons which do not reside in OF/addons/. Also, we shouldn't forget to add appropriate .gitignore rules to ignore the obj folder.

[thiagohersan]

this is huge! makefile addon parsing = ninja. big ups arturo!

(I can do more testing for osx and android...)

[danzeeeman]

I'll pull this tonight. In route to Austin, Tx. On Jan 16, 2013 2:13 PM, "Thiago Hersan" notifications@github.com wrote:

this is huge! makefile addon parsing = ninja. big ups arturo!

(I can do more testing for osx and android...)

— Reply to this email directly or view it on GitHubhttps://github.com/openFrameworks-RaspberryPi/openFrameworks/pull/116#issuecomment-12334689.

[underdoeg]

This sounds great.

@bilderbuchi

I think it would be better if that obj folder would be within the addon folder, i.e. addons/ofx*/obj/platform, no?

I agree that it would be more logical that way and maybe this is overprotective. But I am a little afraid that you might accidentally commit the obj/ folder. Personally I wouldn't think that there is compiled files in my ofx* folder without reading about it. I know you should always check what you commit but you know...

[edit] about gedit: https://live.gnome.org/Gedit/Plugins/ExternalTools

[arturoc]

I think it would be better if that obj folder would be within the addon folder, i.e. addons/ofx*/obj/platform

yes this seems the most logical to me too, but given how limited parsing inside the makefiles is i was having big trouble to manage to make it that way, using addons/obj was way easier.

about commiting objects by accident i think the rules that avoid it are already in the root gitignore so it shouldn't happen.

[bilderbuchi]

yes this seems the most logical to me too, but given how limited parsing inside the makefiles is i was having big trouble to manage to make it that way, using addons/obj was way easier.

ok, I'll take your word for it. I was assuming this would be equivalent in complexity to how the src/libs/... folders are identified

also, @underdoeg has a point about the commit stuff. if we put them in an OF-controlled location, we can make sure that it's ignored. If addon authors have to manage themselves, there's bound to be mistakes. We could ameliorate that, though, by making sure there's a rule in the ofxTemplate .gitignore (just checked, it's already in). Not everybody will use that, though. Well, as long as that folder stays out of any git repos, I'm happy :-)

also, cheers for that gedit link. gonna try that out for sure.

[arturoc]

Well, as long as that folder stays out of any git repos, I'm happy :-)

didn't thought of that but it actually makes it better option to have the obj's outside the addons that way they always get ignored by the OF rules

[jvcleave]

@arturoc do you need us to test anything specifically in order to merge?

[arturoc]

would be great if someone could test with the latest xcode, i don't have any computer with lion so can't test it my self

also android under osx, @thiagohersan if you could give that a try?

[jvcleave]

Here is what I tested:

OS X 10.8.2, Xcode 4.4 (not latest)

Ran make in openFrameworks/libs/openFrameworksCompiled/project - all good

Copied openFrameworks/scripts/osx/template into myApps and built and ran - all good

I am not up to speed with the status of the projectGenerator is but I tried the one in openFrameworks/apps/devApps/projectGenerator and got

clang: error: no such file or directory: '/Volumes/WORK_IN_PROGRESS/OPENFRAMEWORKS/RPI_REFERENCE/openFrameworks/apps/devApps/projectGenerator/../../../addons/ofxXmlSettings/libs/tinyxmlparser.cpp'
clang: warning: -lpthread: 'linker' input unused when '-c' is present
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

[arturoc]

mmh, that's weird, do other examples using ofxXmlSettings work for you? i've tried in linux and osx and it works for me. i'm getting a duplicated symbol when compiling the old PG though, looking into it now

On 01/18/2013 09:53 AM, Jason Van Cleave wrote:

Here is what I tested:

OS X 10.8.2, Xcode 4.4 (not latest)

Ran |make| in |openFrameworks/libs/openFrameworksCompiled/project| - all good

Copied |openFrameworks/scripts/osx/template| into myApps and built and ran - all good

I am not up to speed with the status of the projectGenerator is but I tried the one in |openFrameworks/apps/devApps/projectGenerator| and got

clang: error: no such file or directory:'/Volumes/WORK_IN_PROGRESS/OPENFRAMEWORKS/RPI_REFERENCE/openFrameworks/apps/devApps/projectGenerator/../../../addons/ofxXmlSettings/libs/tinyxmlparser.cpp' clang: warning: -lpthread:'linker' input unused when'-c' is present Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed withexitcode 1

— Reply to this email directly or view it on GitHub https://github.com/openFrameworks-RaspberryPi/openFrameworks/pull/116#issuecomment-12413238.

[bilderbuchi]

hm that file exists (at least in current develop), the path looks correct, too. maybe clang can't deal with the path including the /..? although that would be really surprising...

[jvcleave]

I added ofxXmlSettings to an empty project and it compiled

The problem is the PG Xcode project thinks tinyxml* is in openFrameworks/addons/ofxXmlSettings/libs

when the correct path is openFrameworks/addons/ofxXmlSettings/libs/tinyxml/src

[bilderbuchi]

This is most probably due to 870fdcb70bf293e08feed29a80ad7531c7fa374c by @bakercp, which just corrected the file locations. probably all IDE project files for the PG have to be updated. similar for the PG-simple?

[thiagohersan]

on osx 10.8 with xcode 4.5.2.

I put the following in a Makefile inside a few of the examples (like examples/math/noiseField2dExample/):

OF_ROOT=../../.. OF_SHARED_MAKEFILES_PATH=$(OF_ROOT)/libs/openFrameworksCompiled/project/makefileCommon includes $(OF_SHARED_MAKEFILES_PATH)/config.project.make

and everything compiled fine.

Also tested on a few examples in examples/addons (openCV, 3DModel, assimp, svg, xml).

make, make run, make all, make clean... all worked fine !

just one thing didn't work: make clean doesn't remove the .apps from bin/

will test android later today or tomorrow...

[bakercp]

Just clarification -- is it normal for a "run" target to simply run the executable and not be dependent on any build phases? Would one normally just do something like:

make && make run if you wanted to do it in one line?

[arturoc]

@jvcleave so the problem is with xcode? i though it was with the makefiles. also while trying that i've realized that when theres more than the src folder object files get added twice to the linking phase, will fix it tomorrow

@thiagohersan thanks will take a look at those too.

should this be: .DEFAULT_GOAL=Release ?

i think for OF the best is to have the default target as all since most of the times you call make on the OF library is when you install so better to have both targets compiled

@bakercp yes i think it make sense to add a dependency from the run target to build, will add that too

[arturoc]

also xcode-select -print-path would be great, i'll try in older versions to check if it works, or i can check that and try the others if that fails

[bakercp]

@arturoc only issue with adding the dependency to make run is that it's kind of slow on RPi :/

[arturoc]

i can add a buildandrun target :)

[bakercp]

+1 for buildandrun

oF plays by its own rulez!

[thiagohersan]

makes sense for default to be all. make help says the default is Release and when I was testing make, make Debug, clean, clean Release, clean Debug, etc... I noticed an extra Debug build in there : )

but yeah, makes sense to build all at once.

also, is there a note about the PLATFORM_OS option somewhere? make help explains PLATFORM_VARIANT. maybe there can be a note about PLATFORM_OS there too.

[bilderbuchi]

i have to say I expected make run to automatically build if needed, then run it, so -1 to buildandrun (we're picking up make targets left and right...), and +1 to adding a build dependency. what use is running, if the compiled code is not in sync with the codebase? or are you worried that checking if build is needed is too slow on rpi?

[bakercp]

@bilderbuchi yeah, the build check phase is an "unbearable" 8-10 seconds. make run (with an included build phase) is more intuitive overall and if people like me can't handle the wait on the Pi, then they can just run it with ./bin/example. I therefore retract my +1 for buildandrun, give it a -1 and give a build-phase-dependent make run a +1. :) And maybe I'll learn some patience in the process.

[bilderbuchi]

otoh, 8-10s is pretty long, and accumulates to a lot of wasted time. I already grumble when I have to compile (being spoiled by heavy use of scripting languages), I think every second saved is worth it, I wasn't aware only the build check would be that long.

[bakercp]

Yeah, I wouldn't change my vote still, as I believe the build-phase+run == make run is best for the majority of systems. Perhaps we could make an exception somehow on the pi? I'm not sure. It's basically taking a while for the pi to check the core lib files. So perhaps there is a way faster way to hash / cache the current state. A filesystem watcher or something. I'm just making stuff up now. :)

[arturoc]

with the latest changes i did for android it's now doing some recursive calls so the time has probably doubled

i can try to avoid those recursive calls but it's pretty hard

[bilderbuchi]

well, we already got an issue for compile-time speedup: openframeworks/openFrameworks#255, maybe we should dig that out again ;-)

[bakercp]

Yeah, I've started being very careful about this in my addons. I rarely if ever include ofMain.h / ofConstants.h any more. Certainly worth taking another pass at the core. Has anyone taken a pass at this?

[thiagohersan]

line 281 here has the \ that osx grep doesn't like.

after changing that the src/ files compile fine.

but, the afterplatform steps don't happen properly because the ABIS_TO_COMPILE variable is empty (see the comments above).

and... config.android.default.make might be missing something like this to define RESFILE/RESNAME:

RESNAME=$(shell echo $(APPNAME)Resources | tr '[A-Z]' '[a-z]') RESFILE=$(RESNAME).zip

after adding that stuff everything seems to compile/create fine.

is make install supposed to create the .apk? it didn't work from the command line, but if I open Eclipse and run the app from there using the Eclipse flow, it works fine and runs on the phone and everything.

[bilderbuchi]

@bakercp not that I know of..

[arturoc]

there's for sure no includes to ofMain.h anymore, includes to ofConstants.h are necessary unless we divide it in several files. but usually ofConstants.h is not that problematic unless you modify it.

[arturoc]

does that works? not ideal but there doesn't seem any official way to do it, even cmake does some trick similar to this

[jvcleave]

@arturoc - yeah - my original problem was with the PG Xcode project, not the make files. I was trying to generate examples but I should have just tried the make files :)

with a27cb1d I am getting this error

../../../libs/openFrameworksCompiled/project/osx/config.osx.default.make:82: *** invalid syntax in conditional. Stop.

however if I use @thiagohersan's line in place it works for me MAC_OS_SDK_PATH=$(shell xcodebuild -sdk -version | grep "SDKs/MacOSX" -m 1 | sed 's/^[^/]*\(.*\)\/[^/]*/\1/')

[thiagohersan]

The problem I see with xcode-select is that for some (older ?) installs the xcode tool location and sdks are separate.

I believe that in those installs the xcode-select -print-path command will return something like: /Developer/Applications/Xcode.app/Contents

while the SDKs are in: /Developer/SDKs

I think the original way might be the best way for now.

I'll PR something...

[arturoc]

ive tried with xcodebuild but it doesn't work on xcode 3. with xcode-select both in xcode3 and an old xcode4 i got

/Developer

i'll fix the conditional tomorrow

[arturoc]

hey, i'm going to merge this, i've been working with this makefiles for a while (including osx and android) and it works great.

so i'm going to merge them here and then move the corresponding files to develop, we'll loose the history by now, but will be there once we merge the whole branch.

anyway, just in case anyone wanted to add something before merging

[bilderbuchi]

Nothing comes to my mind. Great work Arturo! you don't have to lose the commit logs (if you mean that by history) - you can cherry-pick all the commits in your branch over to develop. Something like this should do the trick (Untested!):

git checkout develop (meaning OF-develop)
git cherry-pick develop-raspberrypi...feature-makefiles

mind the 3 dots! this needs git >= 1.7.1. commits will have new SHAs (of course) but commit changesets and their messages will be preserved.

[arturoc]

mmh, not sure that will work since the raspberry branch already has changes to the makefiles will try though but i think the easiest is to just copy the files by now and then get the whole history when we merge the raspi branch into develop

On 01/31/2013 05:35 PM, Christoph Buchner wrote:

Nothing comes to my mind. Great work Arturo! you don't have to lose the commit logs (if you mean that by history) - you can cherry-pick all the commits in your branch over to develop. Something like this should do the trick (Untested!):

git checkout develop (meaning OF-develop) git cherry-pick develop-raspberrypi...feature-makefiles

mind the 3 dots! this needs git >= 1.7.1. commits will have new SHAs (of course) but commit changesets and their messages will be preserved.

— Reply to this email directly or view it on GitHub https://github.com/openFrameworks-RaspberryPi/openFrameworks/pull/116#issuecomment-12951217.

[bilderbuchi]

hm in that case you're probably right. you just have to pay attention when moving the files, to not get merge conflicts when you then merge the raspi branch later.

[bakercp]

Merging into the main repo is great. I'd say go for it, especially if you can preserve the history. It's good for all of our github cred!

[arturoc]

i can't keep the history right now as there's too many commits but every commit will be there once we merge the raspberry branch into the main OF repo.

[bakercp]

go for it!