Hi,
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.
Actually I'm trying out the new build system to finally use it to do Debian packages using the unified build, which in my view seems like a good idea. However I see some issues with that. For one, running curl to download stuff from the web while building is not acceptable in a Debian package, which has to build without net connection as well. (Actually it would be nice to have the Externals-HOWTO in CVS anyways.)
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.)
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.
Ciao
On Dec 6, 2005, at 7:57 AM, Frank Barknecht wrote:
Hi,
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.
Actually I'm trying out the new build system to finally use it to do Debian packages using the unified build, which in my view seems like a good idea. However I see some issues with that. For one, running curl to download stuff from the web while building is not acceptable in a Debian package, which has to build without net connection as well. (Actually it would be nice to have the Externals-HOWTO in CVS anyways.)
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.
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
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
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <checkout.patch><installer-externals.patch>
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
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.
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.
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?
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
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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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.
Which reminds me: Debian's policy handles documentation in some special way, which I need to read up on, but things like html-docs, pdf-Howtos etc. should be in /usr/share/doc/pd-something, whereas we can keep the patches in /usr/lib/pd/doc. Moving the files with Debian's package tools is easy, however if they are called from Pd (like the html-manual) we need to take special care. Though, for now I would be happy to get a current package of pd with externals running, wherever the docs show up in the end.
Ciao
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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.
Which reminds me: Debian's policy handles documentation in some special way, which I need to read up on, but things like html-docs, pdf-Howtos etc. should be in /usr/share/doc/pd-something, whereas we can keep the patches in /usr/lib/pd/doc. Moving the files with Debian's package tools is easy, however if they are called from Pd (like the html-manual) we need to take special care. Though, for now I would be happy to get a current package of pd with externals running, wherever the docs show up in the end.
Ciao
It might be better to have every pd distibution have the same directory strucure under pd/ and then add symlinks/aliases/shortcuts in system-specific directories according to the particular distribution for a particular setup of a particular operating system operated by a particular human with particular taste in directory structure that day.
Martin
On Dec 6, 2005, at 6:58 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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.
Which reminds me: Debian's policy handles documentation in some special way, which I need to read up on, but things like html-docs, pdf-Howtos etc. should be in /usr/share/doc/pd-something, whereas we can keep the patches in /usr/lib/pd/doc. Moving the files with Debian's package tools is easy, however if they are called from Pd (like the html-manual) we need to take special care. Though, for now I would be happy to get a current package of pd with externals running, wherever the docs show up in the end.
Ultimately, it would be a good idea to have all the txt, HTML, pdf, etc. in /usr/share/doc/pd-something, but until we have a real help-browser solution worked out, we have the Help menu. And for that to work, all of the docs have to be in one directory, and /usr/lib/pd/doc makes the most sense for now.
But once we have a help browser, it should be pretty easy to create a build with the txt,html,pdf, etc. stuff separate. You would just define $(manualsdir) from the command line, like:
export DESTDIR=/path/to/build/ make prefix=/usr DESTDIR=$DESTDIR manualsdir=$DESTDIR/usr/share/doc/pd-something install
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach