On 30.01.2013 10:41, Stefan Sperling wrote:
>> # 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.
Yes. It is in fact a bad idea to add specific flags just for GTest.
>>> # 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])
Do not rely on GTest's configure. Just refer to the GTest sources
directly in our build.conf, and let our makefile build it. In fact, this
is the only sane way to eventually make it work on Windows.
>>> # 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.
We should simply ignore it since we will not be running GTest tests,
we'll be using GTest for running our tests. Hence, as I said above, we
can just ignore the GTest configury and simply compile their sources
into two libraries (libgtest_main and libgtest). Refer to GTest build to
find which sources belong where, but other than that, ignore it.
The GTest sources are completely standalone and do not require any
external dependencies in order to be used as a test framework.
>>> # 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.
We already have magic in place to see if we need to add -lpthread to the
link lines. And in fact it's irrelevant for building the GTest libraries
-- it only matters when building the test binaries, IIRC.
Whether we want GTest itself to use threads is another question -- I
think the answer is a definite no for now; I can't think of a good
reason to write multithreaded tests at this point.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-01-30 11:34:51 CET