On Jun 27, 2006, at 9:34 AM, geiger wrote:
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
The Pd-extended build system should be able to handle this right now. Each section is easily buildable on its own by doing: make ggee, make zexy, make pdp, make iemlib, etc. And it is quite easy to redirect the install location of make pdp_install, make zexy_install, etc.
Yes, but still I have to do prepare a package each time something went wrong. And there are more things that can go wrong than one generally thinks.
I also like to have the possibility to only install pd, and not hundreds of externals which I won't use, and which I think noone should use and which just use up disk space.
There is undoubtedly a lot of cruft. Part of what I think we should do with Pd-extended is to make a standard way of deprecating cruft. But that takes a lot of work. So in the meantime, Pd-extended ships with a lot of cruft.
The way Pd-extended is now is by no means a finished product, its just one of the stepping stones to a Pd platform. I think its time to stop wasting time making separate build systems and distros for each platform. The amount of time that people have wasted on issues due to the separate distros is massive. The amount of time people have to wait because the package is 25 megs bigger than it should be is not very big. We can then put that effort into going forward on all platforms.
Sorry, I just do not agree. Most of the things can be done with Pd builtin objects. If we would not try to maintain useless stuff we
would save even more time. If people wouldn't have to try several externals and versions before finding the right object to do their things they would save time.
All of libc can be written in C, yet basically no one writes C
programs without libc. libc is not small, there is a lot of stuff in
there. Pd needs to have a lot of stuff included before its anywhere
near as flushed out as libc. We really cripple ourselves if we do
not build and use libraries, whether those libraries are written in C
or Pd or whatever. I would rather create music than rewrite an
object that someone else has already created and debugged. For
example, I would have no idea how to write a feedback delay network
in Pd, it would take me a long time to figure out how, and then debug
it. But luckily someone else has done it. And it took me 20 minutes
to get it working how I wanted it to.
I agree that stuff is a mess as it is now. That's why I think we
should work on standard libraries and deprecate things as we have
useful replacements. But Pd as Miller distributes it just too small
compared to all of the useful work that people have done. Many of
the projects I have done quite simply could not be accomplished using
that set of objects.
<snip> > > Once we have the automatic nightly builds setup, that should catch a > lot of problems. Moving it to Debian proper shouldn't be a big deal > then.
It might not be a big deal, but it is work, and there are quality
checks in Debian that are not that easy to surpass. Being able to build is
only one step. We might be lucky, but I do not think that the Debian people share your opinion about quality, so I am in for trouble, and it
will be hard for me to justify the size of the package, especially if I am not convinced myself.Then, there is also the possiblity to maintain packages outside of
Debian, which might be easier.
I think Debian quality checks are a good idea. If we have a unified
build system, then all platforms would be more likely benefit from
the Debian quality checks.
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler