On Tue, Jan 29, 2013 at 10:39:03AM -0800, Ben Reser wrote:
> On Tue, Jan 29, 2013 at 9:37 AM, Gabriela Gibson
> <gabriela.gibson_at_gmail.com> wrote:
> > Please see the attachment for a long long list of questions :)
>
> Would have been easier for me to look at this if you'd just have
> included it inline in the email or at least as a text/plain attachment
> (your mailer seems to have decided it was application/x-shellscript,
> so I had to save the file in order to read it).
I agree that reading text inline rather than in attachments
is more convenient. Old-fashioned text-email interface (mutt)
user here :)
> One idiom around the list is people including blocks of code, output,
> etc wrapped like so:
>
> [[[
> some code here
> ]]]
>
> Which would have worked pretty well for this email.
>
> To that end I've included your file quoted below with such changes:
Thanks Ben!
I'm replying to some of Gabriela's questions below:
> > The longer I look at the build system, the more confused I get, so I
> > think now is a good time to take stock and ask some questions.
> >
> > First of all, a list of the 'storyline' of the build system I think is
> > happening:
> >
> > http://wiki.apache.org/subversion/Build%20System%20Map2
> >
> > this is not complete, currently it just lists what autogen.sh,
> > build.conf, configure.ac, gen-make.py contain. There are a few
> > dustbunnies hiding there :)
> >
> > Now my current guess as to what I need to do:
> >
> > [[[
> > # code for build.conf I think I should add
> >
> > dnl Search for gtest --------------
> > $svn_lib_gtest = "no"
> > dnl use build/ac-local/gtest.m4 to set things up.
> > GTEST_LIB_CHECK(1.6.0)
> > if test "$svn_lib_gtest" = "yes"; then
> > AC_DEFINE([SVN_HAVE_GTEST], 1,
> > [Defined if gtest is enabled])
> > fi
> > dnl
> > ]]]
> >
> > and then what? I cannot see how to tell the build system to use this info.
In configure.ac, extend BUILD_RULES, INSTALL_RULES, and
STATIC_INSTALL_RULES as appropriate. It may help to look at how
this is done for other optional dependencies, such as kwallet (which
is probably a good example to refer to because it also relies on C++).
This controls the rules that gen-make.py will consider when generating
Makefiles based on information from build.conf.
The configure script also produces the file subversion/svn_private_config.h
which maps configure script results to C preprocessor constants
(#define FOO bar) which we can use in the source code to detect how
the build was configured.
In your case the define would say
#define SVN_HAVE_GTEST 1
if gtest was found. If it wasn't found, SVN_HAVE_GTEST won't be defined.
So in the source code this maps to:
#ifdef SVN_HAVE_GTEST
and:
#ifndef SVN_HAVE_GTEST
respectively.
> > [[[
> > # ----------------------------------------------------------------------------
> > #
> > # Gtest targets
> > #
> >
> > [gtest]
> > description = Gtest Test Suite
> >
> > type = lib
> > path = gtest
> > sources = src/*.cc
> > install = gtest-install
> >
> > # there are headers in 2 places:
> > # /home/g/trunk/gtest/include/gtest/internal/gtest-port.h
> > # /home/g/trunk/gtest/include/gtest/
> > # this causes autogen.sh to complain -- do we have a headers2 I can use?
> > headers = include/gtest
> >
> > # find and set these flags initially, do we need to add a --gtest-CXXFLAGS=?
> > # or does the bogstandard CXXUSERFLAGS suffice?
I think just CXXUSERFLAGS is fine.
> > compile-cmd = $(GTEST_CXXFLAGS)
> >
> > # find and set these flags initially, do we need to add a --gtest-LDFLAGS=?
> > link-cmd = $(GTEST_LDFLAGS)
> >
> > ========================================================================
> > # Code from/for gtest.m4 I think I should add / or otherwise use
> >
> > AC_ARG_WITH([gtest],
> > [AS_HELP_STRING([--with-gtest],
> > [Enable tests using the Google C++ Testing Framework.
> > ])],
> > [],
> > [with_gtest=no])
> >
> >
> > # not sure how to do this: need user set variable? Set a default that
> > # can be overridden with (say) --gtest-config=/trunk/gtest/scripts?
> > AC_ARG_VAR([GTEST_CONFIG],
> > [The exact path of Google Test's 'gtest-config' script.])
> > GTEST-CONFIG = "scripts/gtest-config"
> > # but note the perms being set from the gtest configure.ac:
> > AC_CONFIG_FILES([scripts/gtest-config], [chmod +x scripts/gtest-config])
> >
> >
> > # What to do with this? --gtest-CPPFLAGS option for configure?
> > AC_ARG_VAR([GTEST_CPPFLAGS],
> > [C-like preprocessor flags for Google Test.])
> > GTEST_CPPFLAGS = CXXCPP
> >
> > # What to do with this? --gtest-LIBS option for configure?
> > AC_ARG_VAR([GTEST_LIBS],
> > [Library linking flags for Google Test.])
> >
> > # de we need the versioning check? Gtest hasn't been updated in ages,
> > # seems to be mature
> > AC_ARG_VAR([GTEST_VERSION],
> > [The version of Google Test available.])
> > ]]]
> >
> > it looks like
> > https://svn.apache.org/repos/asf/subversion/trunk/build/ac-macros/serf.m4
> > has a few useful bits I could rewrite.
> >
> > [[[
> > # path & version check (note that AM_ macros are not working at all,
> > # nor is AS_IF) do we need this check? We already ensure python
> > # >=2.5?
> >
> > # TODO(chandlerc_at_google.com): Currently we aren't running the Python tests
> > # against the interpreter detected by AM_PATH_PYTHON, and so we condition
> > # HAVE_PYTHON by requiring "python" to be in the PATH, and that interpreter's
This is bad. The python binary might not even be called 'python'
on a given system (e.g. it might be called 'python2.7'). You don't
need to address this right away, but eventually we should fix this.
> > # version to be >= 2.3. This will allow the scripts to use a "/usr/bin/env"
> > # hashbang.
> > PYTHON= # We *do not* allow the user to specify a python interpreter
> > AC_PATH_PROG([PYTHON],[python],[:])
> > AS_IF([test "$PYTHON" != ":"],
> > [AM_PYTHON_CHECK_VERSION([$PYTHON],[2.3],[:],[PYTHON=":"])])
> > AM_CONDITIONAL([HAVE_PYTHON],[test "$PYTHON" != ":"])
> >
> > ========================================================================
> > # Configure pthreads. There is ~/trunk/gtest/m4/acx_pthread.m4 and it
> > # looks like we need it. does this need translating? Ie. the AM_ /
> > # AS_IF macros rewritten?
This should probably check whether APR was compiled with thread support,
and obtain the appropriate pthread linking flags from APR somehow, if
possible. It will likely work as-is for now, but we should keep this in
mind as well.
> > AC_ARG_WITH([pthreads],
> > [AS_HELP_STRING([--with-pthreads],
> > [use pthreads (default is yes)])],
> > [with_pthreads=$withval],
> > [with_pthreads=check])
> >
> > have_pthreads=no
> > AS_IF([test "x$with_pthreads" != "xno"],
> > [ACX_PTHREAD(
> > [],
> > [AS_IF([test "x$with_pthreads" != "xcheck"],
> > [AC_MSG_FAILURE(
> > [--with-pthreads was specified, but unable to be used])])])
> > have_pthreads="$acx_pthread_ok"])
> > AM_CONDITIONAL([HAVE_PTHREADS],[test "x$have_pthreads" == "xyes"])
> > AC_SUBST(PTHREAD_CFLAGS)
> > AC_SUBST(PTHREAD_LIBS)
> > ]]]
> >
> > thanks for any advice you might have!
Received on 2013-01-30 10:42:08 CET