[PD] building all external on linux

[IOhannes m zmoelnig]

� wrote:
> 
>>- it doesn't handle libraries
> 
> on purpose. if one external fails to build all you loose is this external.
> all the rest can still be used, until it this is fixed.
> libraries are a bad way to organize pd externals, we should try to
> make it as modular as possible. this is key to collaboration.

i don't understand this at all.
what makes structuring code as libraries vs. singular externals a "key 
to collaboration" ?
i mean, i cannot collaborate better or worse just because a bunch of 
c-files are compiled into one binary or because one c-file compiles into 
a bunch pd-objects.

> 
> imagine the linux kernel would be like pd, in order to get my
> network card running, i would have to load the coxlib, except for
> the eepro card, which is in the libthorvalds, which currenlty doesn,t
> build because of a typo in the rtl module.....

which is basically like it is ;-)
to get my network card running i have to use 8139too.ko except for my 
wlan-card where i have to use ndiswrapper, which currently doesn't work 
because even windoze has no 64bit drivers for it.... (of course, we can 
blame broadcom to not give away there specs in the first place, but it 
still doesn't work)

to get you more involved: i have to compile the realtime-lsm module in 
order to make pd/gem work with chromium with -rt.

and most probably there is also a weird (void*)-cast error in the 
eepro-code of libthorvalds (although i didn't get there because of the 
typo in the rtl)

>>- it doesn't handle flext externals
> 
> flext has its own build system. its not the goal to handle this
> 
>>- it doesn't handle special compile time flags / configure scripts /
>>  whatever
> 
> 
> it shouldn't. special compile flags and configure are evil. make it
aha

>>- it's using old pd header files (0.37)
> 
> its doing this because no one updated it. So this is a bad
> argument from someone who is able to do so.

as carmen has pointed out, no one should have to update it.
imo, it is bad by design to use a local (dead) copy of a header-file 
when there is living one next door.


anyhow, zexy is split into one file per object to go better into the 
built system (for most objects; i have no idea how to handle objects 
like [&&~] within that context)

but still, out there in the wild there are some objects that form 
"natural" groups


mfg.asdr.a
IOhannes