Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long compilation on raspberry pi #12

Open
fred-dev opened this issue Jul 11, 2018 · 7 comments
Open

Long compilation on raspberry pi #12

fred-dev opened this issue Jul 11, 2018 · 7 comments

Comments

@fred-dev
Copy link

Could the includes be structured differently to decrease complication time, for example I need to include ofxmidi even when I don't use MIDI, I also see all of the possible modules getting compiled when I know I am only using a single oscillator. I am guessing this is difficult. It is ok on my windows machine, but compiling on raspberry pi takes a really long time for something not so complex. I also feel it slow down code sense (or whatever it is called there) in Xcode.

@npisanti
Copy link
Owner

as i also use ofxPDSP on the raspberry, i am aware that the compilation is really long as this is a really big library (more than 13000 lines of code). But anyway it has to compile everything just once, or there is something that retriggers the compilation each time?

@fred-dev
Copy link
Author

Maybe it is something specific to me, randomly when I make minor changes the whole of ofxpdsp will recompile. This is also true for all the add-ons I use when this happens (not sure what triggers it, the last time I added a single ifdef). I guess in theory it should only compile once but on reality this is not the case. But cool, thanks anyway, you can close this I guess

@npisanti
Copy link
Owner

i found that compiling some addons on other projects on the rpi retrigger the compilation of all the addons, expecially if you compile ofxOMXPlayer in another project and then ofxPDSP the latter will be forced to recompile, one of the cause could be that ofxPDSP has different compiler flags (it enables the NEON intrinsics for SIMD operations). I usually edit libs/openFrameworksCompiled/project/linuxarmv6l/config.linuxarmv6l.default.mk and change vfp to PLATFORM_CFLAGS += -mfpu=neon

@npisanti
Copy link
Owner

i also remove all the ADDONS_CFLAGS in ofxSIMDFloats for those platforms as they are set in config.linuxarmv6l.default.mk

linuxarmv6l:
	# ofxSIMDFloats is not useful without NEON, this flags are for running it on a raspbian rpi2
	ADDON_CFLAGS = -mfpu=neon -mfloat-abi=hard -ftree-vectorize
	
linuxarmv7l:
	# enable NEON as is not enabled by default, i'm assuming this is a raspberry Pi / other ARMhf
	ADDON_CFLAGS = -march=armv7-a -mfpu=neon -mfloat-abi=hard -ftree-vectorize

@npisanti
Copy link
Owner

if your problem is this, changing the headers inclusion won't improve the situations, as oF compiles all the .cpp for the addons anyway

@fred-dev
Copy link
Author

Wow, great, thanks for fast response and tips. It thought it would only compile following a hierarchy of included headers, good to learn more. The OMX player explains some of my finger tapping time.

@npisanti
Copy link
Owner

i think it's a bit complicated... headers are always compiled everytime (so if you want something to be inlined you write it there), so it's important to streamline the inclusions, .cpp files are compiled just once, and are recompiled if one of the included headers change. But a change of compiler flags retriggers the .cpp compilation. I don't know if the compilation of all the addons with different compiler flags for each addon could be possible, the makefile system it's a bit an arcane art.

@npisanti npisanti changed the title Long compilation Long compilation on raspberry pi Jul 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants