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
[email protected]
http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
