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).
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:
> Hi,
>
> 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.
>
> [[[
> # ----------------------------------------------------------------------------
> #
> # 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?
> 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
> # 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?
> 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-29 19:39:43 CET