[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