[PD] building all external on linux
hans at eds.org
Tue Apr 12 18:13:48 CEST 2005
On Apr 12, 2005, at 5:59 AM, Tim Blechmann wrote:
>>>> Those have their own build system. No one has added them to the
>>>> externals/build setup. Ideally everything would be built there...
>>> well, i don't think that the external build system as it is at the
>>> moment is the best way to build externals:
>> its the best and most stable build system that we have had.
>> I mean its not been changed since its beginning and it is still
>> working. compare this with the build system in pd devel and you
>> know what i mean :)
> sure ... on the other hand, it's currently failing to compile some
> externals ;-)
rm failed_external.c ../src/failed_external.c
That's all you need to do to compile the rest. Or even better, fix the
>>> - 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.
>> 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.....
> i know, what you mean ... still, there are externals that use shared
> code. the most elegant way to use this shared code is to pack externals
> into libraries ..
The best of all worlds is to use objects as individual files that call
the shared code in a dynamic lib.
> and if i build "all" externals, i want to build "all" externals, and
> "all", except for toxy, pyext, cyclone, zexy ...
>>> - it doesn't handle flext externals
>> flext has its own build system. its not the goal to handle this
> why not? flext externals are also pd externals ... and pretty important
They have a separate build system.
>>> - it doesn't handle special compile time flags / configure scripts /
>> it shouldn't. special compile flags and configure are evil. make it
>> simple and robust. the makefile for the externals has ten lines of
>> code, not more (well someone added the ugly and completely useless
>> optimization flags later ...).
> hm ... i don't think, compile time flags are evil ... if i want to
> denormals in some weird external, i haven't written, i'd like to use
> -mfpmath=sse -msse flags in order to do my floating point computations
> on the sse unit and use the DAZ feature of the hardware (that is
> in devel)
I'll second that.
>>> - 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.
> of course, but someone might have the idea to compile all externals
> against another version of pd than the latest ... imo, binding a build
> system to a specific version of pd, is not really the best way ...
Check my other email on this topic, and the -I../../../pd/src addition
I just committed.
> cheers ... tim
> mailto:TimBlechmann at gmx.de ICQ: 96771783
> latest mp3: kMW.mp3
> latest cd: Goh Lee Kwang & Tim Blechmann: Drone
> After one look at this planet any visitor from outer space
> would say "I want to see the manager."
> William S. Burroughs
"The arc of history bends towards justice."
Martin Luther King, Jr.
More information about the Pd-list