[PD-dev] pd-extended: flatspace, external-libs, aliases

Hans-Christoph Steiner hans at eds.org
Mon Jan 15 01:59:57 CET 2007


On Jan 12, 2007, at 5:04 AM, Georg Holzmann wrote:

> Hallo Hans+list!
>
> As I added some more externals to the buildsystem now, I have some  
> more questions:
>
>
> 1) flatspace (externals/build/src) :
>
> I see there are now a lot of doubled objects there (e.g. zexy,  
> iemlib, iemmatrix, ... is now all in the libdir format) - so I only  
> want to ask if I can remove these deprecated objects here ?
>
> And a general question about the flatspace: what should go in  
> there ? All externals, which only exist of one object ?
> And what is this externals/build/externals.pd file for (which  
> doesn't include all objects) ?

Günter started that collection because he felt that Pd should have  
just one carefully controlled global namespace.  He doesn't like the  
namespace stuff, so I just leave flatspace as is so that it can be  
used as is.  The namespace stuff is still experimental, so it's good  
to have other methods of organizing Pd to compare it against.  That  
means leaving duplicates in externals/build/src/.


> 2) external libraries:
>
> How do we handle this (e.g. ann, which needs the ann library) -  
> should we e.g. make an directory somewhere where these libraries  
> are downloaded (so they don't have to be in pd-cvs) and then build  
> with the buildsystem and linked to the externals statically ?
>
> At least for not that big libraries it would be an option ... what  
> do you think or how is this handled now ?

I think something like ann should probably be distributed separately  
as a pre-built libdir.  To be included in Pd-extended, the external  
sources need to be available in the Pd CVS (like GemLibs) or in each  
OS's package management (Fink on Mac OS X; apt-get on Debian/Ubuntu;  
yum on Fedora Core).

>
> in externals/build/README you write:
>
> <cite>
> In order to add an external that needs libraries to this build  
> system, create
> a "libs" file with the exact same name as the source file (i.e.  
> oggread~.c and
> oggread~.libs).  If the .libs file has cross-platforms library  
> options, it
> should go into "externals/build/src".  .libs files for platform- 
> specific library
> options go in "externals/build/PLATFORM"
> </cite>
>
> but in these .libs files are only the flags for the linker ...

Yup, that's right.  Currently the Pd-extended build system doesn't  
work well for more complicated builds.  It's just a matter of someone  
doing the work.  I think the best route would be to create a global  
autoconf/automake system.  Bryan Jurish recently outlined such a  
system on this list.

http://lists.puredata.info/pipermail/pd-dev/2006-12/008114.html

> 3) Multiple-Files externals:
>
> again, your description in externals/build/README says this:
> <cite>
> In your "externals/build/src/OBJECT.c" file, #include the other  
> files that need to be
> compiled and linked in.  See how the chaos externals are included:
> </cite>
>
> I guess this was just a quick hack ... ;)
> So I build now various libraries with multy-Files externals and  
> will update this documentation if you don't mind !

externals/build/README is for the externals/build stuff (aka  
flatspace) so that instruction is correct for only that section.  I  
think that instruction should stay, but a note should be added saying  
it only applies to that section.

> 4) Aliases:
>
> your README:
> <cite>
> In the "externals/build/src/OBJECT.c" file, add a function with the  
> alias name
> with "_setup" appended to it.  Then make a symlink to original  
> external binary
> file that is named using the alias.
> </cite>
>
> How do you do that now ? Because I can't see any symlinks ATM ...
>
> But maybe it's a better approach to make pd-wrapper patches (at  
> least where it is possible) ... maybe in the directory of the  
> externals ?
>
> E.g. in iemmatrix
>            - src
>            - help
>            - abs
>            - aliases -> and here the alias patches ?
>
> Of course it would be optimal, if those could be auto-generated ... ;)
>
> (Problem is, that the helpfiles won't work - in any case)

I actually think that aliases are bad practice and I don't support  
them at all in Pd-extended.  No other programming language that I  
know has aliases for functions or objects.  Functions and objects  
only ever have one single name.  Aliases make code harder to read,  
are extra work to support, reduce the namespace, while the only  
benefit is saving a few keystrokes.  Instead, I think people should  
spend more time coming up with a very good name.

.hc


>
>
>
> So I'm curious what you and the others think about this !
> LG
> Georg
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


------------------------------------------------------------------------

News is what people want to keep hidden and everything else is  
publicity.          - Bill Moyers






More information about the Pd-dev mailing list