Re: Updated pg_buildext
От | Christoph Berg |
---|---|
Тема | Re: Updated pg_buildext |
Дата | |
Msg-id | 20110618181228.GB19843@msgid.df7cb.de обсуждение исходный текст |
Ответ на | Re: Updated pg_buildext (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Updated pg_buildext
|
Список | pgsql-pkg-debian |
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/
Вложения
В списке pgsql-pkg-debian по дате отправления: