this patch allows devel/subversion to optionally: * build with apache2 instead of standalone apr * build swig python bindings Fix: patch available at http://ntu.clkao.org/tmp/svn-port.diff
I have applied this patch to my install and it is a significant improvment. I recommend that it be applied to the ports collection. Best, Clark
Responsible Changed From-To: freebsd-ports-bugs->bmah Over to Maintainer.
State Changed From-To: open->feedback Interesting! Any chance of updating your patch to work with the 0.24.2 version of subversion, which I just committed earlier today? Couple of questions: You removed the dependency on expat. Do we really not need this? It almost feels like the WITH_MOD_DAV_SVN and WITH_APACHE2 options could be combined. Is there a case where you would build WITH_APACHE2 but not WITH_MOD_DAV_SVN? The conditional in the pre-extract target isn't correct but I think I'd like to reword this message to make sense no matter what build-time options get passed to the port. Thanks!
On Thu, Jun 19, 2003 at 03:14:13PM -0700, Bruce A. Mah wrote: > Any chance of updating your patch to work with the 0.24.2 version of > subversion, which I just committed earlier today? the patch is updated and tested at the original url :) > Couple of questions: You removed the dependency on expat. Do we > really not need this? IIRC expat is not directly used in svn but in the apr level. so i think we should let apr to depend it. > It almost feels like the WITH_MOD_DAV_SVN and WITH_APACHE2 options > could be combined. Is there a case where you would build WITH_APACHE2 > but not WITH_MOD_DAV_SVN? consider there are some deployment boxes that already have apache2 installed, the option just allows it to build against it instead of building duplicated apr. of course building extra mod_dav_svn would be no harm, but the prompt needs to be more desriptive. and I thought the WITH_APACHE2 option also used in other ports is a convention. > The conditional in the pre-extract target isn't correct but I think I'd > like to reword this message to make sense no matter what build-time > options get passed to the port. maybe we need a ports-wide option displaying/assigning macro? same repeating things are happening all over the tree. Cheers, CLK
If memory serves me right, Chia-liang Kao wrote: > On Thu, Jun 19, 2003 at 03:14:13PM -0700, Bruce A. Mah wrote: > > Any chance of updating your patch to work with the 0.24.2 version of > > subversion, which I just committed earlier today? > > the patch is updated and tested at the original url :) Thanks, that was fast! > > Couple of questions: You removed the dependency on expat. Do we > > really not need this? > > IIRC expat is not directly used in svn but in the apr level. so i think > we should let apr to depend it. OK. It turns out that neon (which we also depend on) needs expat as well. So we can nuke this. > > It almost feels like the WITH_MOD_DAV_SVN and WITH_APACHE2 options > > could be combined. Is there a case where you would build WITH_APACHE2 > > but not WITH_MOD_DAV_SVN? > > consider there are some deployment boxes that already have apache2 > installed, the option just allows it to build against it instead of > building duplicated apr. of course building extra mod_dav_svn would > be no harm, but the prompt needs to be more desriptive. and I thought > the WITH_APACHE2 option also used in other ports is a convention. Hmmm. I checked all the other ports that use WITH_APACHE2 and they all use WITH_APACHE2 to mean "use Apache 2.X instead of Apache 1.X". I'm concerned about overloading the meaning of this option, since you want to use it to mean "use Apache 2.X instead of no Apache". (Note that I've seen a WITHOUT_APACHE option, but of course that isn't what we want either.) > > The conditional in the pre-extract target isn't correct but I think I'd > > like to reword this message to make sense no matter what build-time > > options get passed to the port. > > maybe we need a ports-wide option displaying/assigning macro? same > repeating things are happening all over the tree. Yeah. Kind of outside the scope of this PR but I agree with you. I'm going to do is commit the "remove expat dependency" part of your patch now. I haven't tested WITH_SWIG_PY yet but I'll do that next and commit it. Still want to think about WITH_APACHE2. Sorry for being overly-cautious...this is a new port for me and I am still learning how it interacts with other ports. Thanks! Bruce.
If memory serves me right, Bruce A. Mah wrote: > I'm going to do is commit the "remove expat dependency" part of your > patch now. I haven't tested WITH_SWIG_PY yet but I'll do that next and > commit it. Still want to think about WITH_APACHE2. We have a small problem: stennis:subversion% uname -a FreeBSD stennis.packetdesign.com 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Tue Jun 3 12:01:31 PDT 2003 root@stennis.packetdesign.com:/usr/obj/usr/src/sys/NIMITZ5 i386 stennis:subversion% sudo make WITH_SWIG_PY=yes [lots of output deleted] /bin/sh /usr/users/bmah/FreeBSD/ports/subversion/work/subversion-0.24.2/libtool --silent --mode=compile cc -D_REENTRANT -D_THREAD_SAFE -DSWIGPYTHON -O -pipe -mcpu=pentiumpro -g -O2 -DNEON_ZLIB -DNEON_SSL -I/usr/local/include/python2.2 -I./subversion/include -I. -I/usr/local/include/neon -I/usr/local/include/db4 -I/usr/local/include/apr-0 -I/usr/local/include/apr-0 -I/usr/local/include -o subversion/bindings/swig/swigutil_py.lo -c ./subversion/bindings/swig/swigutil_py.c subversion/bindings/swig/swigutil_py.c:52:2: #error The python bindings require threads. APR was compiled without threads. *** Error code 1 Stop in /usr/users/bmah/FreeBSD/ports/subversion/work/subversion-0.24.2. *** Error code 1 Stop in /usr/users/bmah/FreeBSD/ports/subversion. Any ideas? Thanks, Bruce.
State Changed From-To: feedback->analyzed I guess technically the correct state for this PR is now "analyzed".
oh right, forgot to mention that python binding requires apr or apache2 to be built with threads (which finally works now with the frebsd_thread_hacks in apache2) maybe we should have that in the prompt too. On Fri, Jun 20, 2003 at 09:51:41AM -0700, Bruce A. Mah wrote: > subversion/bindings/swig/swigutil_py.c:52:2: #error The python bindings require threads. APR was compiled without threads. > *** Error code 1 > > Stop in /usr/users/bmah/FreeBSD/ports/subversion/work/subversion-0.24.2. > *** Error code 1 > > Stop in /usr/users/bmah/FreeBSD/ports/subversion. > > Any ideas?
If memory serves me right, Chia-liang Kao wrote: > oh right, forgot to mention that python binding requires > apr or apache2 to be built with threads (which finally > works now with the frebsd_thread_hacks in apache2) > > maybe we should have that in the prompt too. Ummm...maybe, except: intruder:bmah% cd /usr/ports/devel/apr intruder:apr% grep -i thread Makefile So unless we modify the apr port to allow it to build with threads, WITH_SWIG_PY requires WITH_APACHE2 (or whatever we end up calling it). This is getting a little messy... :-p Bruce. > On Fri, Jun 20, 2003 at 09:51:41AM -0700, Bruce A. Mah wrote: > > subversion/bindings/swig/swigutil_py.c:52:2: #error The python bindings req > uire threads. APR was compiled without threads. > > *** Error code 1 > > > > Stop in /usr/users/bmah/FreeBSD/ports/subversion/work/subversion-0.24.2. > > *** Error code 1 > > > > Stop in /usr/users/bmah/FreeBSD/ports/subversion. > > > > Any ideas?
Bruce, Thank you for responding. I'm primarly interested in using the correct APR, ie, WITH_APACHE2_APR would be perfect. I found that using the regular APR causes random issues that go away when using the APR that ships with Apache. I wish I had cash to throw your way, perhaps next year (*grins*). I'd rather have the SWIG stuff be in another port, IMHO, beacuse it is quite complicated bugger in and of itself. Also, I'd rather use PyRex or some other C/Python binding (SWIG is icky). One other issue (which is hard to track down) is that the port doesn't seem to "install" on occasion. I typically use the same ports collection to target several "images". Usually a port is smart enough to know if it isn't installed in that image (I do a chroot jail with /usr/ports mounted). Sometimes I have to help by removing a .installed file in the work directory; but it seems that there is nothing short of completely deleting the work directory to cause it to install a second time (on a different image). Is there some file it's looking for other than .installed? Thanks. I hope this helps. Thank you *so* much for being maintainer! Best, Clark On Wed, Jun 25, 2003 at 07:58:34AM -0700, Bruce A. Mah wrote: | If memory serves me right, Clark C. Evans wrote: | > Howdy. I forget who, but someone on #svn gave me the following older | > patch to the subversion port that lets it build correctly, using the | > APR that ships with Apache and not using its own version. | | Sigh. IMHO, "correctly" is a matter of interpretation. | | Anyways, the port used to do this when I submitted the | WITH_MOD_DAV_SVN patches to the then-MAINTAINER but he wanted me to | change it to its current form. I'm not opposed to the change in | principle but the way it's implemented in the patch needs a tweak or | two. | | > Could you please apply this? | | See: | | http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/53190 | | As you can tell there are some problems with the patch. I have to | figure out how to deal with the "needs threads for SWIG bindings" | problem in a way that won't cause a bazillion users to email me about | a program that I'm just learning to use myself. | | I think I'm going to change WITH_APACHE2 in the patch to | WITH_APACHE2_APR and apply that part...when I get some time to work on | this that is. | | Thanks, | | Bruce.
If memory serves me right, Clark C. Evans wrote: > Thank you for responding. I'm primarly interested in using the > correct APR, ie, WITH_APACHE2_APR would be perfect. I found that > using the regular APR causes random issues that go away when using > the APR that ships with Apache. *What kind* of random issues? > I wish I had cash to throw your > way, perhaps next year (*grins*). :-) I have appended a new patch that *just* does the WITH_APACHE2_APR stuff. I'm having problems with it because I get run-time link errors if I'm installing WITH_APACHE2_APR and the devel/apr port is installed. I believe the run-time linker gets confused by the presence of the devel/apr libraries. I don't like this situation because of the potential for foot-shooting. I'm also running into some problems with the httpd.conf munging that I hadn't seen before. Briefly, the port puts the mod_authz_svn module before the mod_dav_svn module in the configuration file. I don't remember seeing this problem before, so I'm quite confused by this. > I'd rather have the SWIG stuff be in another port, IMHO, beacuse it > is quite complicated bugger in and of itself. Also, I'd rather use > PyRex or some other C/Python binding (SWIG is icky). Well, the SWIG bindings are supported by the subversion team, and that's what almost anyone building on top of subversion (e.g. ViewCVS) will expect. That's about all I know about this part of the program. > One other issue (which is hard to track down) is that the port > doesn't seem to "install" on occasion. I typically use the same > ports collection to target several "images". Usually a port is > smart enough to know if it isn't installed in that image (I do > a chroot jail with /usr/ports mounted). Sometimes I have to help > by removing a .installed file in the work directory; but it seems > that there is nothing short of completely deleting the work directory > to cause it to install a second time (on a different image). Is > there some file it's looking for other than .installed? Thanks. "make reinstall"? I can't recall having problems like this but I wouldn't rule out some other problems. Bruce. Index: Makefile =================================================================== RCS file: /home/pcvs/ports/devel/subversion/Makefile,v retrieving revision 1.35 diff -u -r1.35 Makefile --- Makefile 23 Jun 2003 21:40:48 -0000 1.35 +++ Makefile 26 Jun 2003 18:44:20 -0000 @@ -6,6 +6,7 @@ PORTNAME= subversion PORTVERSION= 0.24.2 +PORTREVISION= 1 CATEGORIES= devel MASTER_SITES= http://subversion.tigris.org/files/documents/15/4807/ MASTER_SITES+= ${MASTER_SITE_LOCAL} @@ -16,8 +17,7 @@ LIB_DEPENDS= db4:${PORTSDIR}/databases/db4 \ neon.23:${PORTSDIR}/www/neon \ - expat.4:${PORTSDIR}/textproc/expat2 \ - apr-0.9:${PORTSDIR}/devel/apr + expat.4:${PORTSDIR}/textproc/expat2 INSTALLS_SHLIB= yes @@ -28,17 +28,15 @@ CONFIGURE_ARGS= --with-ssl \ --with-neon=${LOCALBASE} \ --with-berkeley-db=${LOCALBASE}/include/db4:${LOCALBASE}/lib \ - --with-apr=${LOCALBASE} \ - --with-apr-util=${LOCALBASE} \ --with-swig=no MAN1= svn.1 svnadmin.1 MANCOMPRESSED= no -.if defined(WITH_MOD_DAV_SVN) APXS=${LOCALBASE}/sbin/apxs -BUILD_DEPENDS+= ${APXS}:${PORTSDIR}/www/apache2 -RUN_DEPENDS+= ${APXS}:${PORTSDIR}/www/apache2 + +.if defined(WITH_MOD_DAV_SVN) +WITH_APACHE2_APR= yes CONFIGURE_ARGS+= \ --with-apxs=${APXS} PLIST_SUB+= MOD_DAV_SVN="" @@ -47,12 +45,30 @@ PKGDEINSTALL= NONEXISTENT .endif +.if defined(WITH_APACHE2_APR) +APACHE2_PORT?= ${PORTSDIR}/www/apache2 +BUILD_DEPENDS+= ${APXS}:${APACHE2_PORT} +RUN_DEPENDS+= ${APXS}:${APACHE2_PORT} +CONFIGURE_ARGS+=--with-apr=${LOCALBASE}/lib/apache2/apr-config \ + --with-apr-util=${LOCALBASE}/lib/apache2/apu-config +.else +LIB_DEPENDS+= apr-0.9:${PORTSDIR}/devel/apr +CONFIGURE_ARGS+=--with-apr=${LOCALBASE} \ + --with-apr-util=${LOCALBASE} +.endif + pre-extract: .if !defined(WITH_MOD_DAV_SVN) @${ECHO_MSG} @${ECHO_MSG} "You can enable the mod_dav_svn module for Apache 2.X" - @${ECHO_MSG} "by defining WITH_MOD_DAV_SVN." + @${ECHO_MSG} "by defining WITH_MOD_DAV_SVN. This option implies + @${ECHO_MSG} "the WITH_APACHE2_APR option." +.endif +.if !defined(WITH_APACHE2_APR) @${ECHO_MSG} + @${ECHO_MSG} "You can link subversion against the APR built with" + @${ECHO_MSG} "the www/apache2 port, rather than the devel/apr port," + @${ECHO_MSG} "by defining WITH_APACHE2_APR." .endif post-extract:
Responsible Changed From-To: bmah->lev Hand to new maintainer.
State Changed From-To: analyzed->closed - The URL in the original PR doesn't exist anymore. - Subversion is on version 0.32.1 in the ports tree. - Most of what has been discussed in this PR has been imported. Thanks for your support!