ofxPDSP icon indicating copy to clipboard operation
ofxPDSP copied to clipboard

Long compilation on raspberry pi

Open fred-dev opened this issue 7 years ago • 7 comments

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.

fred-dev avatar Jul 11 '18 09:07 fred-dev

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?

npisanti avatar Jul 11 '18 21:07 npisanti

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

fred-dev avatar Jul 12 '18 11:07 fred-dev

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 avatar Jul 12 '18 13:07 npisanti

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 avatar Jul 12 '18 16:07 npisanti

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

npisanti avatar Jul 12 '18 16:07 npisanti

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.

fred-dev avatar Jul 12 '18 16:07 fred-dev

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 avatar Jul 13 '18 08:07 npisanti