[PD] building all external on linux

[Hans-Christoph Steiner]

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 ;-)

(in "externals/build/PLATFORM")
rm failed_external.c ../src/failed_external.c
make

That's all you need to do to compile the rest.  Or even better, fix the  
problem :-).

>
>>> - 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  
> not
> "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
> ones...

They have a separate build system.

>
>>> - it doesn't handle special compile time flags / configure scripts /
>>>   whatever
>>
>> 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  
> avoid
> 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  
> enabled
> 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.

.hc

>
> cheers ... tim
>
> --  
> mailto:TimBlechmann at gmx.de    ICQ: 96771783
> http://www.mokabar.tk
>
> latest mp3: kMW.mp3
> http://mattin.org/mp3.html
>
> latest cd: Goh Lee Kwang & Tim Blechmann: Drone
> http://www.geocities.com/gohleekwangtimblechmannduo/
>
> 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."
                                                               Dr.  
Martin Luther King, Jr.