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@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@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