npisanti / ofxPDSP

openFrameworks addon for audio synthesis and generative music
Other
303 stars 37 forks source link

Long compilation on raspberry pi #12

Open fred-dev opened 6 years ago

fred-dev commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.