[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: building against subversion using autoconf

From: jeremy hinds <jeremy.hinds_at_gmail.com>
Date: Sun, 9 Mar 2008 14:44:14 -0700

On Sat, Mar 8, 2008 at 4:40 PM, Jack Bates <ms419_at_freezone.co.uk> wrote:
> I'm working on an Apache module, like mod_dav_svn, but using mod_atom to
> support Subversion repository access with the Atom Publishing Protocol,
> RFC 5023: http://code.google.com/p/mod-atom-svn/
>
> I was inspired by the last paragraph of the Repository Access Layer
> section of the Subversion book:
> http://svnbook.red-bean.com/nightly/en/svn.developer.layerlib.html#svn.developer.layerlib.ra
>
> I'm following mod_dav_svn's example, but confess I'm stuck linking with
> Subversion's shared libraries. In general, is there a resource anywhere
> suggesting how projects can use autoconf to build against Subversion?
>
> To build against Apache, I stole the autoconf / automake setup from
> mod-skeleton: http://code.google.com/p/modskeleton/
>
> First, on Debian Subversion's headers are installed
> in /usr/include/subversion-1. Not sure if this is typical? Is it
> preferable to use #include <subversion-1/svn_fs.h> or use #include
> <svn_fs.h> and -I/usr/include/subversion-1? After reading the autoconf
> manual, I wonder if we should use AC_CHECK_HEADER(svn_fs.h)? I guess the
> former has consequences if one wants to build against a Subversion build
> directory, instead of where Subversion is installed on the system?
>
> Second, on Debian Subversion's shared libraries are split into
> libsvn_fs-1.so, libsvn_ra-1.so, etc. Again, not sure if this is typical
> or if our autoconf setup should anticipate building against an
> amalgamated libsvn-1.so on some systems? And again, I guess we should
> use AC_CHECK_LIB(libsvn_fs-1)?

I can't speak for all package managers, but both of these things are
consistent with svn builds and from source, as well as rpm installs
that I've seen. But if you discover that there are cases where
"svn_fs.h" is not in that subdirectory, rather than fiddling with
"-I<path>", I think the right thing to do is

AC_CHECK_HEADERS([subversion-1/svn_fs.h svn_fs.h])

and then in your .c or .h:

#include <config.h>

#if defined (HAVE_SUBVERSION_1_SVN_FS_H)
# include <subversion-1/svn_fs.h>
#elif defined (HAVE_SVN_FS_H)
# include <svn_fs.h>
#endif

Are you planning to have apxs do the actual compilation once autoconf
finds where things are installed? I'm not familiar with the relative
merits of that vs invoking gcc directly, so this is question is more
for my own benefit.

>
> I'll continue studying my autoconf references, but if anyone with more
> experience can point out the "right" way to build against Subversion,
> it'd be much appreciated! A resource suggesting how projects can use
> autoconf to build against Subversion would be ideal...
>
> Incidentally, I'm not using mod_dav, but I am trying to follow
> mod_dav_svn's example, and struggling to understand the mod_dav
> repository interface. The best documentation I found is mod_dav.h, but
> I'm still struggling for a high level picture of how mod_dav's interface
> works. For instance, how is the root_dir which is passed to get_resource
> of dav_hooks_repository calculated? How are get_resource and deliver
> related? Where in mod_dav_svn is dav_resource_private defined?
>
> Nick Kew's Apache Modules Book has been a great reference, but
> unfortunately it doesn't touch on mod_dav. I'll continue reading the
> source, but if anyone can suggest a faster way of getting up to speed on
> mod_dav_svn, it'd also be much appreciated!
>
> Thanks and best wishes, Jack
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-09 22:44:34 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.