[PD-dev] Re: Pd for Debian [was: Re: [PD] Pd-0.38.4-extended-RC6 release]
Hans-Christoph Steiner
hans at eds.org
Wed Dec 28 00:40:22 CET 2005
On Dec 27, 2005, at 1:57 AM, Frank Barknecht wrote:
> Hallo,
>
> over to pd-dev...
>
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>> On Dec 26, 2005, at 1:32 PM, Frank Barknecht wrote:
>>> I'm currently trying to adapt the debian build files in CVS to use
>>> Hans' global makefile, a lot of help comes from Martin Rumori in this
>>> task. In fact he did most of the work so far. We managed to build
>>> installed packages which basically follow Hans' makefile and do
>>> everything, his make system does. However I don't want to put any
>>> work
>>> into pd-0.38 anymore, so these are for pd-0.39 (or CVS head) and
>>> don't
>>> include the libdir or comment patches by Hans. They haven't been
>>> published yet, it's still christmas time here. Probably this will
>>> take
>>> till 2006 anyway.
>>
>> Why not include the libdir patch? It applies fine with 0.39 and its a
>> safe change, its not major surgery. Which is the comment patch?
>
> I don't know, where it is, but you support international characters in
> pd-extended, right? That's what I'm refering to.
Ah, ok, I thought I documented this somewhere, but maybe I forgot to.
In packages/patches, all the patches used for Pd-extended are checked
into CVS. You can apply/unapply them by:
cd packages && make patch_pd
cd packages && make unpatch_pd
The int'l char patch is super simple, and it seems to work ok, so I
think it'd be good to include. Part of my goal with the Pd-extended
build system was to have a system of managing patches so that we can
have a testing ground before submitting them to Miller, etc. Also, it
allows us to distribute smaller changes to Pd core without the major
surgery of pd-devel.
>>> So far building Debian packages out of Hans' stuff looks very
>>> promising. A problem still is, that Hans' main makefile isn't yet
>>> ready to be used only partially. That is, "make all" works fine, but
>>> "make only_part_of_all" often doesn't.
>>
>> Please report problems so they can be fixed. Which is the main
>> Makefile, packages/Makefile? Which parts aren't working? I know that
>> the clean targets could use some work...
>
> As packaging pd itself is no major problem (in fact, since xmas there
> is a pd-0.39-2 package in testing) I just want to build externals for
> now.
>
> So I do this:
> $ make externals prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
FYI, you can also do this, they are the same thing:
cd externals && make install prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
> It bails out with this:
>
> cd
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals && make
> BUILDLAYOUT_DIR=/home/fbar/pd/packages/packages-neu/packages/pure-
> data/packages
> cvs_root_dir=/home/fbar/pd/packages/packages-neu/packages/pure-data/
> packages/.. DESTDIR=/home/fbar/tmp/pd-pack prefix=/usr
> libpddir=/home/fbar/tmp/pd-pack/usr/lib/pd OPT_CFLAGS="" UNAME=Linux
> make[1]: Entering directory
> `/home/fbar/pd/packages/packages-neu/packages/pure-data/externals'
> cc -DPD
> -I/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> pd/src -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -Wno-shadow
> -DUNIX -Dunix -fPIC -o
> "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/build/src/ENV.o" -c
> "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/build/src/ENV.c"
> cc -Wl,-export_dynamic -shared -o
> "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/build/src/ENV.pd_linux"
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/hcs/hid/input_arrays.o
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/hcs/hid/hid_linux.o
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/hcs/hid/hid.o -lm -lc
> cc:
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/hcs/hid/input_arrays.o: No such file or directory
> cc:
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/hcs/hid/hid_linux.o: No such file or directory
> cc:
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/hcs/hid/hid.o: No such file or directory
> make[1]: ***
> [/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/build/src/ENV.pd_linux] Error 1
> rm
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../
> externals/build/src/ENV.o
> make[1]: Leaving directory
> `/home/fbar/pd/packages/packages-neu/packages/pure-data/externals'
> make: *** [externals] Error 2
That's very strange. I can't reproduce this on Debian, Mac OS X, or
Windows. Its trying to compile [hid] files into the [ENV] object.
Have you don't a "cvs up -Pd" on "externals" and "packages"? Are
there any files in your "externals/build/src" which are not from CVS?
> And actually I want to build externals without Gem, as Gem also has
> nice Pd packages and may be easier built from its own CVS. I would at
> least vote for making Gem, PDP/Pidip and Gridflow their own targets
> inside the makefile, like "make gem(_install) gridflow(_install)
> pdp(_install)"
cd externals && make pdp_install
cd externals && make pidip_install
I know nothing about building GridFlow, and Gem can be compiled by:
cd packages && make gem_install
Personally, I think that the Debian packages should reflect the other
Pd-extended builds and just be one package. I could see separating out
the Pd core, so that you could use different versions with the same
pd-extended externals, docs, etc. but that might cause problems since
some externals might only work properly with the version of Pd that
they were compiled against.
I just don't see any advantage to having all of this stuff separated
into separate packages. For example, Gem is useless without Pd, and if
its not being used it does no harm, it just takes up disk space.
The one small advantage I could see is having a package that would have
objects without dependencies, but that could be a lot of work to
create. Even some of the objects in externals/build/src have some
dependencies (though that could be easily changed).
> Then Pd is not configured to use the prefix given in the make command:
>
> $ make pd prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
> cd
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/
> src/ && autoconf
> echo $MACOSX_DEPLOYMENT_TARGET
>
> cd
> /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/
> src && ./configure --enable-jack && \
> make
> BUILDLAYOUT_DIR=/home/fbar/pd/packages/packages-neu/packages/pure-
> data/packages
> cvs_root_dir=/home/fbar/pd/packages/packages-neu/packages/pure-data/
> packages/.. DESTDIR=/home/fbar/tmp/pd-pack prefix=/usr
> libpddir=/home/fbar/tmp/pd-pack/usr/lib/pd OPT_CFLAGS="" UNAME=Linux
>
> I think, this should be " ./configure --enable-jack prefix=$prefix" or
> similar.
If Pd had a proper autotools build system, then it would be:
./configure --enable-jack --with-prefix=$prefix
But it does not, it has a kind of hacked up version. The current setup
barely uses ./configure, for example. Therefore, its much easier to
just override the Makefile variable using:
make prefix=$prefix
.hc
________________________________________________________________________
____
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos
Williams
More information about the Pd-dev
mailing list