[PD-dev] Re: Restructuring of CVS/externals
Hans-Christoph Steiner
hans at eds.org
Thu Feb 2 20:11:56 CET 2006
On Feb 2, 2006, at 7:58 AM, Georg Holzmann wrote:
> Hallo!
>
>>> - lead maintainers get chosen for each library (it could be more
>>> than one person)
>> sounds ok, though - just for the archives - these libraries should be
>> structured themselves into sub-libraries (via subdirs), which could
>> be maintained by other people than the parent lib.
> of course ...
>
>> while having things like [pix_video] and [pdp_qt] in the same package
>> (as in: sub-package of the stdlib) "graphics:pixel:input" makes some
>> functional sense, it will only confuse people into trying to connect
>> [pix_video] to [pdp_xv].
> yes, I also think that Gem and pdp should have different
> parent-folders (and also Gridflow) ...
>
>>>> Symlinks possible from an external in one CVS directory?
>> on w32?
> this does not solve the problem of symlinks, but why not just make a
> different folder for "pd-stdlib", e.g. CVS/pdlib
> (well, pdlib is not a good name, ... but I have no other one now ... ;)
>
> And something else, which is very important i think: the build system.
> There should be a common build system, so that developers don't have
> to write makefiles, configure-scripts etc. when they write an object
> for this pd-stdlib ...
> this means:
> - the buildsystem should be able to compile externals with more then
> one c file and also with h files ...
> - should be able to handle dependencies to external C/C++-libraries
> (e.g. libsndfile ...)
> - also flext externals should be integrated in that system
>
> Then it would be also easy to make packages of such a pd-stdlib ...
Most definitely, I agree with all of these, but the work needs to be
done to make this work. The current one needs work in this regard. I
think using autoconf is probably inevitable and not a bad thing.
Unfortunately, these questions are not easy...
The current externals/Makefile can build multi-file externals (see
"hid" target), and use .h files(see "hid" target), and it can handle
external dependencies (see "pdogg" target). Its not very clean, and
can be a little whacky, but its relatively simple and it works. But
don't let that stop anyone from improving it!
As for flext, that's a tricky one, that is only going to get more
complicated as people write objects using Thomas' loader functionality.
We might have to restrict subsections to one language... hmm...
.hc
>
>
>> anyhow, i (think i) agree with hans that there is some need for a
>> stdlib
> yes, I also think that this would really make much sense !
>
> LG
> Georg
>
________________________________________________________________________
____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism."
- retired U.S. Army general,
William Odom
More information about the Pd-dev
mailing list