Thread: Updated pg_buildext
Hi, here's my updated pg_buildext script. Most notable changes are the addtion of the "configure" and "install" actions and that it catches more errors (set -e, die() calls). Dimitri, do you think that should go into the next postgresql-common version? (Todo: think about a smart and policy-compliant way to update debian/control. Also, try using with 9.1 modules.) Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
Hi, Christoph Berg <myon@debian.org> writes: > here's my updated pg_buildext script. Most notable changes are the > addtion of the "configure" and "install" actions and that it catches > more errors (set -e, die() calls). I like your changes! I recall that doing the build in the vtarget directory was important in my usage, but it could be that you new -f $makefile style allows to run the build from any directory… > Dimitri, do you think that should go into the next postgresql-common > version? Yes. > (Todo: think about a smart and policy-compliant way to update > debian/control. Also, try using with 9.1 modules.) As we rely on the extension's Makefile I think we're as good as can be for 9.1. For debian/control, we have the mechanism to automatically derive it from supported-versions, we need to reach on a conclusion about its use being safe. The other TODO would be what to do about VPATH unfriendly extensions. Some of them are using subdirectories where to stash regression tests, docs, etc. Then building from another place is a problem: maybe that's why you removed my forcing building in $vtarget? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Re: Dimitri Fontaine 2011-06-18 <m2sjr7m9ra.fsf@2ndQuadrant.fr> > I recall that doing the build in the vtarget directory was important in > my usage, but it could be that you new -f $makefile style allows to run > the build from any directory… I didn't really change that, I just replaced "cd && make" with "make -C". Usually, there won't be a Makefile in the build directory, so $makefile is "-f $srcdir/Makefile" as before. The other case was added for plsh which uses autoconf. (build) - cd $vtarget - make -f $srcdir/Makefile CFLAGS="$cflags $opt" PG_CONFIG="$pgc" VPATH="$srcdir" - cd - + # if a Makefile was created by configure, use it, else the top level Makefile + [ -f $vtarget/Makefile ] || makefile="-f $srcdir/Makefile" + make -C $vtarget $makefile CFLAGS="$cflags" PG_CONFIG="$pgc" VPATH="$srcdir" > > (Todo: think about a smart and policy-compliant way to update > > debian/control. Also, try using with 9.1 modules.) > > As we rely on the extension's Makefile I think we're as good as can be > for 9.1. For debian/control, we have the mechanism to automatically > derive it from supported-versions, we need to reach on a conclusion > about its use being safe. The thread on debian-release wasn't 100% conclusive, but there were voices against automatically updating: http://lists.debian.org/debian-release/2011/04/msg00413.html Here's what I would do: * add all supported (by the package) versions to debian/control, but only build those from supported-versions * have some way to update debian/control (ideally not involving debian/control.in because manual changes to debian/control get lost) * have some way to indicate that we want to build a different set of versions, 1) it would make sense to build 9.1 modules when uploading to experimental now, 2) we need that for apt.postgresql.org > The other TODO would be what to do about VPATH unfriendly extensions. > Some of them are using subdirectories where to stash regression tests, > docs, etc. Then building from another place is a problem: maybe that's > why you removed my forcing building in $vtarget? These probably require full (configure,) build && install cycles for each version. Usually install is invoked via fakeroot, but maybe we can go without. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
Christoph Berg <myon@debian.org> writes: > I didn't really change that, I just replaced "cd && make" with "make -C". Ahah, I missed that. Objection withdrawn! :) > Here's what I would do: > > * add all supported (by the package) versions to debian/control, but > only build those from supported-versions > * have some way to update debian/control (ideally not involving > debian/control.in because manual changes to debian/control get lost) > * have some way to indicate that we want to build a different set of > versions, 1) it would make sense to build 9.1 modules when uploading > to experimental now, 2) we need that for apt.postgresql.org Well, for the “local” set of versions to build, I think the answer is to tweak (dpkg-divert) the supported-versions script. Other than that, the main situation I want to avoid is having to hand-edit the package when a major version of PostgreSQL is dropped from sid at testing freeze time. So +1 for your proposal. >> The other TODO would be what to do about VPATH unfriendly extensions. >> Some of them are using subdirectories where to stash regression tests, >> docs, etc. Then building from another place is a problem: maybe that's >> why you removed my forcing building in $vtarget? > > These probably require full (configure,) build && install cycles for > each version. Usually install is invoked via fakeroot, but maybe we > can go without. I guess it boils down to playing with each extension in debian and seeing where pg_buildext fails… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Hello Christoph, Christoph Berg [2011-06-17 17:25 +0200]: > here's my updated pg_buildext script. Most notable changes are the > addtion of the "configure" and "install" actions and that it catches > more errors (set -e, die() calls). Thanks! Updated in VCS, I'll do a new upload soon. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)