[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