[PD-dev] Re: Pd for Debian [was: Re: [PD] Pd-0.38.4-extended-RC6 release]

[Hans-Christoph Steiner]

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