new build system for gtest & gmock

[Zhanyong Wan (λx.x x)]

Hi, users of gtest and/or gmock,

The primary build system we use for gtest and gmock is autotools,
which is hard-to-maintain and slow. It's also not cross-platform, so
we have to maintain xcode and Visual Studio projects separately.

It has been suggested several times, by different people, that we
switch to a more sane build system. Many of them pointed to CMake
(http://www.cmake.org/).

I just started to read up on CMake, and found this encouraging article
(it's a nice and short read, so I suggest you to read it too if you
haven't):

Why the KDE project switched to CMake -- and how

http://lwn.net/Articles/188693/

(Interesting that they first tried SCons and had to give up.)

With CMake, I hope we can:

- have build scripts that more people can understand and maintain (no
more waiting for rescue by the tiny number of autotools experts on
the list),

- generate xcode and VS projects automatically,

- speed up the build process,

- speed most time on actually improving gtest/gmock instead of fixing
the build system.

I'll spend more time getting familiar with CMake, and want to get the
discussion going while I do that.

Thoughts? Thanks,

--
Zhanyong

[Hady Zalek]

Hi Zhanyong,

Having tried Scons, Ant, Autotools, and finally CMake... I totally
agree. You might even want to check this out: https://svn.boost.org/trac/boost/wiki/CMake
.

Cheers,
Hady

Envoyé de mon iPhone

Le 19 déc. 2009 à 00:30, Zhanyong Wan (λx.x x) <w...@google.com> a
écrit :

[Prashant]

How about using Waf? http://code.google.com/p/waf/

[Lenny Primak]

I went through this exercise recently, and
ant was the hands-down winner.
As a Java guy and well-familiar with ant, ant+cpptasks
combination was brain-dead simple, cross-platform,
and out-of-the-box working.
Never looked back.

[Zhanyong Wan (λx.x x)]

Thanks to everyone who has responded.

One thing I like about CMake is that it has very light dependencies.
You can download pre-built CMake binaries from
http://www.cmake.org/cmake/resources/software.html, or if your
platform isn't on the list, you can compile CMake yourself using a
standard C++ compiler, which you must already have. :-)

It looks like that GYP was specifically designed for Chromium, so I
don't expect its maintainers to put our needs before Chromium's when
there's conflict of interest. It also depends on Python, which we'd
want to avoid since it doesn't come installed on all platforms.

Waf shares many design goals with CMake, but it has the problem of
depending on Python too. Also it doesn't seem to be used by really
complex projects, where CMake is used by KDE.

Ant's dependency on Java makes it a poor choice for many of our users.

I read more about CMake today and started to put together build
scripts for gtest. Now I can build the gtest library itself, all
samples, and most of the tests. The build is much much faster than
the autotools version! The last 20% of the work is always the
hardest, but my experience so far gives me confidence.

Cheers,

2009/12/18 Zhanyong Wan (λx.x x) <w...@google.com>:

--
Zhanyong

[Alexander Demin]

Oh, it seems I've missed something ;-).

It's really great that we move to something more advanced than
autotools/automake/etc because sometimes it's much easier to just hack
and build the sources manually rather than struggling with
auto*-scripts.

CMake looks very mature and portable. Personally I like Python based
build managers like SCons due to its almost unlimited flexibility but
it benefits until you haven't Python somewhere or its version is
wrong. Though SCons can work on quite old versions of Python but
frankly having Python dependency to build isn't great for portability
at all regardless to my love to this language. ;-)

Alexander

2009/12/22 Zhanyong Wan (λx.x x) <w...@google.com>:

[Zhanyong Wan (λx.x x)]

2009/12/22 Alexander Demin <ade...@gmail.com>:

> Oh, it seems I've missed something ;-).
>
> It's really great that we move to something more advanced than
> autotools/automake/etc because sometimes it's much easier to just hack
> and build the sources manually rather than struggling with
> auto*-scripts.
>
> CMake looks very mature and portable. Personally I like Python based
> build managers like SCons due to its almost unlimited flexibility but
> it benefits until you haven't Python somewhere or its version is
> wrong. Though SCons can work on quite old versions of Python but
> frankly having Python dependency to build isn't great for portability
> at all regardless to my love to this language. ;-)

gtest and gmock already have SCons scripts. We use them for testing
gtest/gmock on various platforms. It works mostly fine, but is not
quite easy to maintain (although better than autotools in this
regard). There's always bugs in it that we aren't quite sure how to
properly fix.

CMake looks quite a bit simpler, and seems much faster than SCons in
my experiments (I don't have hard numbers yet - yet a subjective
impression). It also claims to generate native VS and Xcode projects.
SCons generates poor VS projects (basically wrappers for a batch
script that lack true integration with the IDE) and cannot generate
Xcode projects at all.

--
Zhanyong

[Zhanyong Wan (λx.x x)]

2009/12/22 Zhanyong Wan (λx.x x) <w...@google.com>:

> Thanks to everyone who has responded.
>
> One thing I like about CMake is that it has very light dependencies.
> You can download pre-built CMake binaries from
> http://www.cmake.org/cmake/resources/software.html, or if your
> platform isn't on the list, you can compile CMake yourself using a
> standard C++ compiler, which you must already have. :-)
>
> It looks like that GYP was specifically designed for Chromium, so I
> don't expect its maintainers to put our needs before Chromium's when
> there's conflict of interest.  It also depends on Python, which we'd
> want to avoid since it doesn't come installed on all platforms.
>
> Waf shares many design goals with CMake, but it has the problem of
> depending on Python too.  Also it doesn't seem to be used by really
> complex projects, where CMake is used by KDE.
>
> Ant's dependency on Java makes it a poor choice for many of our users.
>
> I read more about CMake today and started to put together build
> scripts for gtest.  Now I can build the gtest library itself, all
> samples, and most of the tests.  The build is much much faster than
> the autotools version!

In fact, the tests run so much faster in CMake (as it hides the test
output by default) that I at first thought I screwed up the build
script and the testing was a no-op. :-) I verified that CMake indeed
ran the tests by making one of them intentionally fail.

--
Zhanyong

[Zhanyong Wan (λx.x x)]

Hi all,

I just committed an experimental CMake build script for gtest to the
SVN trunk, r359. (Thanks to Chandler for the code reviews!) You are
welcome to try it and send me feedback/improvements. You can download
CMake at http://www.cmake.org/cmake/resources/software.html

For your convenience, here's the link to the build script:

http://code.google.com/p/googletest/source/browse/trunk/CMakeLists.txt

Hopefully it's self-documenting. It helps if you already know CMake.
In case you don't, it shouldn't be hard to guess what the script is
doing as the syntax is reasonably intuitive. Of course, you should
check the CMake documentation when in doubt:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html

You can safely skip the parts for building the samples and tests if
you aren't interested in them. Thanks,

2009/12/18 Zhanyong Wan (λx.x x) <w...@google.com>:

--
Zhanyong

[Gavin Heavyside]

Are you using any CMake 2.8 features that aren't in 2.6 (you specify
cmake_minimum_required(VERSION 2.8))? Centos 5 has v2.6 available in
rpmforge, and I'd rather not have to upgrade systems manually unless
there is specific functionality not available in an earlier version.

Thanks,

Gavin

On Dec 29 2009, 7:53 pm, Zhanyong Wan (λx.x x) <w...@google.com>
wrote:

> Hi all,
>
> I just committed an experimental CMake build script for gtest to the
> SVN trunk, r359.  (Thanks to Chandler for the code reviews!)  You are
> welcome to try it and send me feedback/improvements.  You can download

> CMake athttp://www.cmake.org/cmake/resources/software.html

[Zhanyong Wan (λx.x x)]

Hi Gavin,

On Mon, Jan 4, 2010 at 2:13 AM, Gavin Heavyside
<gavin.h...@gmail.com> wrote:
> Are you using any CMake 2.8 features that aren't in 2.6 (you specify
> cmake_minimum_required(VERSION 2.8))?

I'm not sure. I'm new to CMake and 2.8 is the only version I've used.

> Centos 5 has v2.6 available in
> rpmforge, and I'd rather not have to upgrade systems manually unless
> there is specific functionality not available in an earlier version.

FYI, you don't have to upgrade your system. Just download the CMake
2.8 source distribution, build it, and put the built executables in
your PATH. I use it this way.

Could you please try to change 2.8 to 2.6 in the script and see if it
still works? If you do that, please share your result with us.
Thanks,

--
Zhanyong

[Gavin Heavyside]

2010/1/4 Zhanyong Wan (λx.x x) <w...@google.com>

FYI, you don't have to upgrade your system.  Just download the CMake
2.8 source distribution, build it, and put the built executables in
your PATH.  I use it this way.

That's fine for testing or as an individual, but we build on multiple OSes, so every deviation from the system supplied or easily available packages is an overhead I'd prefer to avoid unless it is necessary.
 

Could you please try to change 2.8 to 2.6 in the script and see if it
still works?  If you do that, please share your result with us.

Builds fine for me on Centos 5.2 x86_64, CMake 2.6.4, GCC 4.1.2, using googletest revision 359.  I only changed the minimum required version to from 2.8 to 2.6.  There were a couple of warnings which aren't CMake related, I also get them with an autotools-based build:

gavin@typhoon ~/src/google_testing/trunk
[09:48]$ cmake --version
cmake version 2.6-patch 4
[09:50]$ cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/gavin/src/google_testing/trunk
gavin@typhoon ~/src/google_testing/trunk
[09:50]$ make
[ 33%] Building CXX object CMakeFiles/gtest.dir/src/gtest-all.cc.o
Linking CXX static library libgtest.a
[ 33%] Built target gtest
[ 66%] Building CXX object CMakeFiles/gtest_main.dir/src/gtest_main.cc.o
Linking CXX static library libgtest_main.a
[ 66%] Built target gtest_main
[100%] Building CXX object CMakeFiles/gtest_unittest.dir/test/gtest_unittest.cc.o
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc: In member function âvirtual void<unnamed>::AssertionTest_ASSERT_EQ_NULL_Test::TestBody()â:
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc:3829: warning: passing NULL to non-pointer argument 3 of âstatic testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, T2*) [with T1 = long int, T2 = const char]â
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc: In static member function âstatic void<unnamed>::AssertionTest_ASSERT_EQ_NULL_Test::TestBody()::GTestExpectFatalFailureHelper::Execute()â:
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc:3833: warning: passing NULL to non-pointer argument 3 of âstatic testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, T2*) [with T1 = long int, T2 = int]â
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc: In member function âvirtual void<unnamed>::ExpectTest_EXPECT_EQ_NULL_Test::TestBody()â:
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc:4408: warning: passing NULL to non-pointer argument 3 of âstatic testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, T2*) [with T1 = long int, T2 = const char]â
/home/gavin/src/google_testing/trunk/test/gtest_unittest.cc:4412: warning: passing NULL to non-pointer argument 3 of âstatic testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, T2*) [with T1 = long int, T2 = int]â
Linking CXX executable gtest_unittest
[100%] Built target gtest_unittest
gavin@typhoon ~/src/google_testing/trunk
[09:50]$ make test
Running tests...
Start processing tests
Test project /home/gavin/src/google_testing/trunk
  1/  1 Testing gtest_unittest                   Passed

100% tests passed, 0 tests failed out of 1


I've also built successfully using CMake 2.8.0 on OSX Snow Leopard after changing the minimum required version to 2.6.

Thanks,

Gavin

[Zhanyong Wan (λx.x x)]

Thanks for the note, Gavin! I'll install cmake 2.6.4 and relax the
requirement in CMakeLists.txt.

--
Zhanyong

[Zhanyong Wan (λx.x x)]

I hit some problems when trying to build gtest's samples and more
tests (they aren't built by default) using cmake 2.6.4. Looks like
some commands changed syntax. I'm testing a fix now.

2010/1/5 Zhanyong Wan (λx.x x) <w...@google.com>:

--
Zhanyong

[Manuel Klimek]

One of the problems is that apparently the add_test signature changed.
Especially the only way I found to correctly transport the target path
into the test works only on 2.8.
I found a script that apparently multiple projects use to keep
backwards compatibility, though:

http://code.google.com/p/libarchive/source/browse/trunk/build/cmake/AddTest28.cmake?spec=svn1671&r=1671

Cheers,
/Manuel

--
Manuel Klimek (http://go/klimek)

[Zhanyong Wan (λx.x x)]

Update: I committed r361 to make the script compatible with both cmake
2.6.4 and 2.8.0 (thanks to Manuel for the review). There's still the
target path problem that prevents the Python tests to run correctly on
Windows. Manuel is working on that. Thanks,

2010/1/5 Manuel Klimek <kli...@google.com>:

--
Zhanyong

[Zhanyong Wan (λx.x x)]

Manuel's patch that fixes the problem on Windows has been committed in
r363. Cheers,

--
Zhanyong

[Lenny Primak]

Is the DLL build on windows supported by this?
Thanks

On Jan 6, 1:06 pm, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> Manuel's patch that fixes the problem on Windows has been committed in
> r363.  Cheers,
>
> 2010/1/5 Zhanyong Wan (λx.x x) <w...@google.com>:
>
>
>
> > Update: I committed r361 to make the script compatible with both cmake
> > 2.6.4 and 2.8.0 (thanks to Manuel for the review).  There's still the
> > target path problem that prevents the Python tests to run correctly on
> > Windows.  Manuel is working on that.  Thanks,
>
> > 2010/1/5 Manuel Klimek <kli...@google.com>:
> >> One of the problems is that apparently the add_test signature changed.
> >> Especially the only way I found to correctly transport the target path
> >> into the test works only on 2.8.
> >> I found a script that apparently multiple projects use to keep
> >> backwards compatibility, though:
>

> >>http://code.google.com/p/libarchive/source/browse/trunk/build/cmake/A...

[Zhanyong Wan (λx.x x)]

On Wed, Jan 6, 2010 at 10:26 AM, Lenny Primak <lenny...@gmail.com> wrote:
> Is the DLL build on windows supported by this?

No. Would you like to work on it?

--
Zhanyong

[Lenny Primak]

I know nothing about cmake, so it will take me a long time.
Manuel, do/can you do this?
Anyone else? (make CMake build scripts support DLL builds)
There is a msvc/gtset.def export definition file

On Jan 6, 1:28 pm, Zhanyong Wan (λx.x x) <w...@google.com> wrote:

[Manuel Klimek]

On Wed, Jan 6, 2010 at 7:39 PM, Lenny Primak <lenny...@gmail.com> wrote:
> I know nothing about cmake, so it will take me a long time.
> Manuel, do/can you do this?

I can give it a try (I'll fix the tests on Windows first, though :-),
if I get a pointer to the .def file...

Regarding the .def file: do we think it's not worth to add exporting
only a subset of symbols via macros (gcc supports this, too, and in
C++ land it's by now a good practice to do so, because of the high
runtime cost unused symbols generate). On the other hand, gtest is not
really big, so the runtime cost is probably not a big problem... Just
thinking out loud :-)

Cheers,
/Manuel

[Zhanyong Wan (λx.x x)]

On Wed, Jan 6, 2010 at 12:57 PM, Manuel Klimek <kli...@google.com> wrote:
> On Wed, Jan 6, 2010 at 7:39 PM, Lenny Primak <lenny...@gmail.com> wrote:
>> I know nothing about cmake, so it will take me a long time.
>> Manuel, do/can you do this?
>
> I can give it a try (I'll fix the tests on Windows first, though :-),
> if I get a pointer to the .def file...

The .def file is checked in, under the msvc/ directory.

> Regarding the .def file: do we think it's not worth to add exporting
> only a subset of symbols via macros (gcc supports this, too, and in
> C++ land it's by now a good practice to do so, because of the high
> runtime cost unused symbols generate). On the other hand, gtest is not
> really big, so the runtime cost is probably not a big problem... Just
> thinking out loud :-)

We only export the symbols that are actually needed by a user.

--
Zhanyong

[Manuel Klimek]

2010/1/6 Zhanyong Wan (λx.x x) <w...@google.com>:

> On Wed, Jan 6, 2010 at 12:57 PM, Manuel Klimek <kli...@google.com> wrote:
>> On Wed, Jan 6, 2010 at 7:39 PM, Lenny Primak <lenny...@gmail.com> wrote:
>>> I know nothing about cmake, so it will take me a long time.
>>> Manuel, do/can you do this?
>>
>> I can give it a try (I'll fix the tests on Windows first, though :-),
>> if I get a pointer to the .def file...
>
> The .def file is checked in, under the msvc/ directory.

Ah, thx.

>> Regarding the .def file: do we think it's not worth to add exporting
>> only a subset of symbols via macros (gcc supports this, too, and in
>> C++ land it's by now a good practice to do so, because of the high
>> runtime cost unused symbols generate). On the other hand, gtest is not
>> really big, so the runtime cost is probably not a big problem... Just
>> thinking out loud :-)
>
> We only export the symbols that are actually needed by a user.

In linux via a shared object file without macros? How so?

Cheers,
/Manuel

[Lenny Primak]

Manuel,
The msvc/gtest.def file is only used on windows.
On linux, the shared libraries are/should be built
the 'normal' way and all symbols are exported.
There are no macros, as the google test team does not like them.
I had a patch for them introducing the macros and it was shut down
in favor on the .def file on windows.

On Jan 7, 5:04 am, Manuel Klimek <kli...@google.com> wrote:
> 2010/1/6 Zhanyong Wan (λx.x x) <w...@google.com>:
>
> > On Wed, Jan 6, 2010 at 12:57 PM, Manuel Klimek <kli...@google.com> wrote:

[Lenny Primak]

Manuel, any questions/progress on this?

[Zhanyong Wan (λx.x x)]

Manuel is on vacation. Anyone else wants to take a stab? Thanks,

--
Zhanyong

[Manuel Klimek]

I'm currently looking into that. The def file already seems to be out
of date. Sigh. This sounds like a maintenance nightmare to me. Does
anybody know whether we can at least use the same def file for 64 bit
compilation?

/Manuel

2010/1/15 Zhanyong Wan (λx.x x) <w...@google.com>:

[Manuel Klimek]

Update: it's fairly simple to get a gtest dll from cmake, adding the
.def to the sources of the library and specifying SHARED instead of
STATIC is enough.
But...
- I tried to compile / run the gtest tests with SHARED, but the
problem is that there are so many different compile options and each
needs to export different symbols, thus we'd need multiple .def files
- I get segfaults when running some tests; no idea whether this is a
gtest problem with shared libraries and static objects (they behave
different in MSVC than in gcc), but that would be my guess; I don't
want to waste time looking into this if we don't come to some
maintainable solution here

So Lenny, I could just add a SHARED target for MSVC builds to the
CMakeLists.txt, but we'd not have a clue how many tests would be
supported and you'd have to maintain the .def file...

I'd strongly vote for adding the macros, but of course it's Zhanyong's
call, so if you can't convince him, it's not going to happen :-(

Cheers,
/Manuel

2010/1/28 Manuel Klimek <kli...@google.com>:

[Zhanyong Wan (λx.x x)]

Thanks for looking into this, Manuel!

2010/1/28 Manuel Klimek <kli...@google.com>:

> Update: it's fairly simple to get a gtest dll from cmake, adding the
> .def to the sources of the library and specifying SHARED instead of
> STATIC is enough.
> But...
> - I tried to compile / run the gtest tests with SHARED, but the
> problem is that there are so many different compile options and each
> needs to export different symbols, thus we'd need multiple .def files

Good point.

> - I get segfaults when running some tests; no idea whether this is a
> gtest problem with shared libraries and static objects (they behave
> different in MSVC than in gcc), but that would be my guess; I don't
> want to waste time looking into this if we don't come to some
> maintainable solution here

Good thinking. :)

> So Lenny, I could just add a SHARED target for MSVC builds to the
> CMakeLists.txt, but we'd not have a clue how many tests would be
> supported and you'd have to maintain the .def file...
>
> I'd strongly vote for adding the macros, but of course it's Zhanyong's
> call, so if you can't convince him, it's not going to happen :-(

I'm open to revisiting this decision. It was experimental. What do
you think, Vlad? Thanks,

--
Zhanyong

[Vlad Losev]

2010/1/28 Zhanyong Wan (λx.x x) <w...@google.com>

Thanks for looking into this, Manuel!

2010/1/28 Manuel Klimek <kli...@google.com>:

> Update: it's fairly simple to get a gtest dll from cmake, adding the
> .def to the sources of the library and specifying SHARED instead of
> STATIC is enough.
> But...
> - I tried to compile / run the gtest tests with SHARED, but the
> problem is that there are so many different compile options and each
> needs to export different symbols, thus we'd need multiple .def files

Good point.

> - I get segfaults when running some tests; no idea whether this is a
> gtest problem with shared libraries and static objects (they behave
> different in MSVC than in gcc), but that would be my guess; I don't
> want to waste time looking into this if we don't come to some
> maintainable solution here

Good thinking. :)

> So Lenny, I could just add a SHARED target for MSVC builds to the
> CMakeLists.txt, but we'd not have a clue how many tests would be
> supported and you'd have to maintain the .def file...
>
> I'd strongly vote for adding the macros, but of course it's Zhanyong's
> call, so if you can't convince him, it's not going to happen :-(

I'm open to revisiting this decision.  It was experimental.  What do
you think, Vlad?  Thanks,

Having multiple .def files is an unmaintainable solution. I guess this would be a situation where we have to bite the bullet and start using macros. Lenny has patch submitted for that in issue 214 (also on Rietveld). Manuel, out of curiosity, what are the multiple configurations you had to deal with?
 

Regards,
Vlad

[Manuel Klimek]

2010/1/29 Vlad Losev <vl...@google.com>:

Ignore what I wrote yesterday, I was stupid. Got everything to compile
with shared libs now...
Will investigate some more wrt the test failures...

Cheers,
/Manuel

[Manuel Klimek]

2010/1/29 Manuel Klimek <kli...@google.com>:

Oh my god: git5 sync'ed, had to add 43 new symbols to the .def file...
since there's no way to test that on linux, who'll maintain the .def
file?

Cheers,
/Manuel

[Manuel Klimek]

Outcome from the investigation:
Some tests access global variables from the gtest dll directly (for
example FLAGSgtest_filter from gtest_environment_test.cc). The problem
is that the compiler creates a new global symbol in the executable
when the flag is not declared with __declspec(dllimport), thus causing
segfaults. To solve this, we need to annotate the variables with
__declspec(dllimport) when the declaration is used outside of the
gtest dll compilation. Since we need a macro for that, we can use the
same macro to __declspec(dllexport). Now we're half way to export
symbols anyway, and Zahnyong says he's not opposed to the macro idea.

To sum it up: the best way forward seems to be to add the macros for
symbol exporting - that way we can support the gcc visibility stuff,
too (see http://gcc.gnu.org/wiki/Visibility).

Thoughts?

/Manuel

[Vlad Losev]

2010/1/29 Manuel Klimek <kli...@google.com>

Outcome from the investigation:
Some tests access global variables from the gtest dll directly (for
example FLAGSgtest_filter from gtest_environment_test.cc). The problem
is that the compiler creates a new global symbol in the executable
when the flag is not declared with __declspec(dllimport), thus causing
segfaults. To solve this, we need to annotate the variables with
__declspec(dllimport) when the declaration is used outside of the
gtest dll compilation. Since we need a macro for that, we can use the
same macro to __declspec(dllexport). Now we're half way to export
symbols anyway, and Zahnyong says he's not opposed to the macro idea.

To sum it up: the best way forward seems to be to add the macros for
symbol exporting - that way we can support the gcc visibility stuff,
too (see http://gcc.gnu.org/wiki/Visibility).

Thoughts?

This is starting to look like a compelling solution.
 

[Manuel Klimek]

2010/1/29 Vlad Losev <vl...@google.com>:

>
>
> 2010/1/29 Manuel Klimek <kli...@google.com>
>>
>> Outcome from the investigation:
>> Some tests access global variables from the gtest dll directly (for
>> example FLAGSgtest_filter from gtest_environment_test.cc). The problem
>> is that the compiler creates a new global symbol in the executable
>> when the flag is not declared with __declspec(dllimport), thus causing
>> segfaults. To solve this, we need to annotate the variables with
>> __declspec(dllimport) when the declaration is used outside of the
>> gtest dll compilation. Since we need a macro for that, we can use the
>> same macro to __declspec(dllexport). Now we're half way to export
>> symbols anyway, and Zahnyong says he's not opposed to the macro idea.
>>
>> To sum it up: the best way forward seems to be to add the macros for
>> symbol exporting - that way we can support the gcc visibility stuff,
>> too (see http://gcc.gnu.org/wiki/Visibility).
>>
>> Thoughts?
>>
> This is starting to look like a compelling solution.

Lenny, do you have the patch against the current head version lying
around somewhere?

Cheers,
/Manuel

[Zhanyong Wan (λx.x x)]

Hi Manuel,

2010/1/29 Manuel Klimek <kli...@google.com>:

The only patch from Lenny I could find is the one attached here:

http://code.google.com/p/googletest/issues/detail?id=214

It's against 1.3.0, but perhaps it's close enough for the head. Thanks,

>
> Cheers,
> /Manuel
>

--
Zhanyong

[Manuel Klimek]

2010/2/4 Zhanyong Wan (λx.x x) <w...@google.com>:

Unfortunately it doesn't apply cleanly. And I'm quite surprised why we
wouldn't export some classes completely instead of selecting singular
methods... I'll do some more work on it next week...

Cheers,
/Manuel

>
>>
>> Cheers,
>> /Manuel

[Zhanyong Wan (λx.x x)]

2010/2/5 Manuel Klimek <kli...@google.com>:

Thanks for looking into this, Manuel! That patch was never reviewed,
so use it as you see fit or do it from scratch if that's easier.
Cheers,

>
> Cheers,
> /Manuel
>
>>
>>>
>>> Cheers,
>>> /Manuel
>>>
>>
>>
>>
>> --
>> Zhanyong
>>
>
>
>
> --
> Manuel Klimek (http://go/klimek)
>

--
Zhanyong

[Zhanyong Wan (λx.x x)]

Hi Manuel,

Have you found time for this yet? :) No problem if you are busy, just
let us know if you'd rather Vlad or I work on it. Thanks!

2010/2/5 Manuel Klimek <kli...@google.com>:

--
Zhanyong

[Manuel Klimek]

Vlad wrote me a mail he started working on it, so I didn't :-)

2010/2/23 Zhanyong Wan (λx.x x) <w...@google.com>

[Vlad Losev]

Hi Zhanyong,

I exchanged emails with Michael and it looked like he had no immediate cycles to spare on this CL, so I started to work on it myself. Sorry you didn't make it known to you.

I have mostly complete implementation in the main branch; but I will need to integrate the test file from the open source-branch. I have another CL in the OSS  branch to commit before I can integrate though.

Regards,
Vlad

2010/2/23 Manuel Klimek <kli...@google.com>

[Zhanyong Wan (λx.x x)]

Excellent! Thanks,

2010/2/23 Vlad Losev <vl...@google.com>:

> Hi Zhanyong,
>
> I exchanged emails with Michael and it looked like he had no immediate

s/Michael/Manuel/ ?

--
Zhanyong

[Lenny Primak]

I had a fairly recent patch submitted here:
http://codereview.appspot.com/160050/show

Sorry I haven't been around for a while.

Let me know if this works.

On Feb 4, 3:16 pm, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> Hi Manuel,
>
> 2010/1/29 Manuel Klimek <kli...@google.com>:
>
>
>
> > 2010/1/29 Vlad Losev <vl...@google.com>:
>
> >> 2010/1/29 Manuel Klimek <kli...@google.com>
>
> >>> Outcome from the investigation:
> >>> Some tests access global variables from the gtest dll directly (for
> >>> example FLAGSgtest_filter from gtest_environment_test.cc). The problem
> >>> is that the compiler creates a new global symbol in the executable
> >>> when the flag is not declared with __declspec(dllimport), thus causing
> >>> segfaults. To solve this, we need to annotate the variables with
> >>> __declspec(dllimport) when the declaration is used outside of the
> >>> gtest dll compilation. Since we need a macro for that, we can use the
> >>> same macro to __declspec(dllexport). Now we're half way to export
> >>> symbols anyway, and Zahnyong says he's not opposed to the macro idea.
>
> >>> To sum it up: the best way forward seems to be to add the macros for
> >>> symbol exporting - that way we can support the gcc visibility stuff,

> >>> too (seehttp://gcc.gnu.org/wiki/Visibility).