[PD-dev] Re: Linux-Installer bugfix

Hans-Christoph Steiner hans at eds.org
Tue Dec 6 23:21:08 CET 2005


On Dec 6, 2005, at 1:09 PM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> On Dec 6, 2005, at 7:57 AM, Frank Barknecht wrote:
>>> attached is a small fix to the externals-build Makefile, which I had
>>> to do to let Hans' linux-installer compile several externals.
>>>
>>> Also attached is another patch which I had to apply to fix the
>>> scripts/checkout-developer-layout.sh for me.
>>
>> Great, I am glad you're trying it out.  Please check in your changes
>> directly, especially for small fixes like these.  It'll save us all
>> some work.  I can do it if you don't want to.
>
> The problem was (or is) that I couldn't run a decent "cvs up" for the
> whole day now using my developer account, so I only see the anonymous
> version from yesterday currently. I'll check in fixes like that in the
> future, if that's okay.

Ok, cool, I just check your patches in now since I was checking in  
anyway.  But in the future, feel free to checkin fixes to the build  
system.

>> Yes, using curl in Makefiles is bad form.  The easy workaround is just
>> to prepend those lines with a "-" so that errors in those lines will  
>> be
>> ignored.  But yes, a better solution would be to have the Externals
>> HOWTO in CVS.  Debian packages would be great (as would RPMs, Fink,
>> etc. etc.).  I tried to make everything modular, so that the various
>> packaging systems can break up the chunks how they need to.  I was
>> thinking that there would be a "pd-extended" package which would
>> include all of abstractions, doc, extensions, and externals, with Gem,
>> PDP, and GridFlow being separate packages.
>
> Well, actually I would prefer to split off the pd-core for Debian
> packages, so that users, who don't want to use any externals can still
> install Pd. This fits with the Debian philosophy of putting extensive
> extras and documentation into their own packages. Flext may also be a
> special case: techically it is just a library and some headers and
> thus could be a libflext/libflext-dev package duo.

What I meant is that pd-extended would be a debian package with  
everything but Pd itself in it.  Then you would be free to install  
pd-extended in combo with the Pd of your choosing.  There would be some  
problems with compatibility with some of the features of pd-devel if  
externals are using them, but other wise it would work.  Maybe there  
could be a debian package of just all of the Pd-based files, like  
abstractions and doc, then the compiled stuff would be separate.


>>> Currently I just disable the curl stuff in the central Makefile.
>>> (Btw: Some html-generation is using the <font>-tag, which is
>>> deprecated and even illegal in some dialects of HTML.)
>>
>> Yeah, that's leftover from the old Mac OS X packages.  Feel free to
>> change that stuff.
>>
>>> Then using /usr as a prefix will not install pd in /usr/bin, but  
>>> still
>>> in /usr/local/bin. I haven't found out yet, where to change that.
>>
>> How did you do this?  Which part isn't working?  It should work if you
>> always do this:
>>
>> make prefix=/usr install
>
> I'm not yet that far. ;) Currently I just test the first phase, that
> is, building everything in packages/linux_make/build, so no "make
> install" happens yet.  This is, because later the binaries in
> packages/linux_make/build will be moved into the actually Debian
> packages by the Debian package management tools. Doing this
> "non-instalL", the pd binary files show up in
> packages/linux_make/build/usr/local/bin
>
> So actually what I want to do is a kind of:
> $ make prefix=/usr DESTDIR=debian/build install
> which installs everything into packages/debian/build under the tree
> "/usr"
>
> Do you have any idea, how this could be done?

Ah... a bug.  The problem is that DESTDIR can't be a relative path  
currently.  So you'd have to do something like this:

make prefix=/usr DESTDIR=`pwd`/debian/build install

Ideally, the relative->absolute conversion would happen in the  
Makefile.  I just added a "test_locations" target to the makefiles so  
you can easily see where the files would end up (FYI, this wouldn't  
show the relative paths bug tho):

hans at sla:linux_make > make prefix=/usr DESTDIR=`pwd`/debian/build  
test_locations
PD_VERSION: 0.38.4
PACKAGE_VERSION: extended-RC6
CWD /Users/hans/cvs/pure-data/packages/linux_make
DESTDIR /Users/hans/cvs/pure-data/packages/linux_make/debian/build
PREFIX /usr
BINDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/bin
LIBDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/lib
OBJECTSDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/extra
PDDOCDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/doc
LIBPDDIR  /Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr
LIBPDBINDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/bin
HELPDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/doc/ 
5.reference
MANUALSDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/doc/ 
manuals
EXAMPLESDIR   
/Users/hans/cvs/pure-data/packages/linux_make/debian/build/usr/doc/ 
examples

.hc

>
>> Both when compiling everything, and when doing the final install,  
>> i.e.:
>>
>> cd packages/linux_make
>> make prefix=/usr install
>> cd build
>> make prefix=/usr install
>
> I'm not sure I understand this: do I have to run "make install" in
> "build" as well?
>
> Ciao
> -- 
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

If you are not part of the solution, you are part of the problem.
                                                                          
                            - Eldridge Cleaver





More information about the Pd-dev mailing list