Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Thursday, Mar 18, 2004, at 13:36 America/New_York, Frank Barknecht wrote:
What is the reason to not package OSC inside pd-externals? It doesn't depend on anything special, just std-C-headers, not even any of Pd's "private" headers.
I think this is mostly because its easiest to work along the lines of the build system used. Each debian package represents a different build system. It may not be pretty, but it makes building the packages easier. That's why I ended up doing the same thing with the MacOS X installer.
Actually I would prefer it to have as few packages as possible, each containing as much stuff as needed. I kind of hate having to install lots of small packages when one package could do. Of course, at least on Debian this could be handled with metapackages, so called "tasks". But in general I guess, most package users will prefer not having to download lots of packages as well.
That's why I would prefer, if we could somehow find a build system, that allows externals to install in one common place. The "build" directory isn't that bad in this regard, I think. It just needs maintainance and isn't that fit for flext externals or library dependent externals.
For making Debian packages, it actually isn't that hard to collect externals from various places into one package. It "just" requires several lines like: ... (cd zexy/src; $(MAKE) -f makefile.linux LINCLUDE="-I ../../build/include") # Build flext (cd grill/flext; $(MAKE) -f makefile.pd-linux PDPATH=../../build/include STK="" ) ... in the build and similar ones in the install targets. Now if we could agree on naming conventions, we could even get rid of some of these like let LINCLUDE=PDPATH and so on. This shouts a bit for autoconf, though. ;)
ciao