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@iem.at http://lists.puredata.info/listinfo/pd-dev

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

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