Add static/dynamic runtime support in the CMakeLists.txt

[GoogleCodeExporter]

Current version of the CMakeLists.txt generates project file with static 
runtime support. Attached patch extends this script to allow user choose 
either static or dynamic runtime. 

New option was added USE_STATIC_RT:
- ON: Generate projects with static runtime
- OFF: Generate projects with dynamic runtime

Original issue reported on code.google.com by Dmitriy....@gmail.com on 25 Mar 2010 at 6:59

Attachments:

• google-test-cmake.patch

[GoogleCodeExporter]

Original comment by w...@google.com on 25 Mar 2010 at 7:04

• Changed state: Accepted
• Added labels: OpSys-All, Type-Enhancement, Usability
• Removed labels: Type-Defect

[GoogleCodeExporter]

A note, only Microsoft Visual Studio is supported. However it is possible to 
setup gcc 
to link runtime libraries into the applicaiton.

Original comment by Dmitriy....@gmail.com on 25 Mar 2010 at 7:11

[GoogleCodeExporter]

We decided to key this off CMake's variable BUILD_SHARED_LIBS. If CMake is 
being built 
as a DLL (BUILD_SHARED_LIBS=ON), it has to use /MD. Otherwise, while it can use 
either 
/MT or /MD, the former is preferable, as one doesn't have to have those DLLs 
lying 
around in order for the binary to run.

This policy is in SVN as of (at least) r430.

Original comment by vladlosev on 13 May 2010 at 8:51

• Changed state: Fixed

[GoogleCodeExporter]

My project consists of several static libraries and several DLL/EXE projects. 
Every 
static library has assigned unit test project. Project is compiled with /MD. To 
use 
GTest I have to copy gtest.dll to the unit-test-binary folder or add it to PATH 
variable. IMHO it is inconvenient.

Original comment by Dmitriy....@gmail.com on 14 May 2010 at 6:34

[GoogleCodeExporter]

If you are using Google Test from multiple modules (EXE/DLL), you have to 
compile it as a DLL. Otherwise it will 
not work, as you'll end up with multiple copies of static data.

Original comment by vladlosev on 14 May 2010 at 8:18

[GoogleCodeExporter]

I guess we are not at the same page. 

Following is the list of projects in my build tree:

- utils (static library)
- utils_test (executable; relies on utils, GTest)
- system (static library)
- system_test (executable; relies on system, GTest)
- fix_engine (static librray; relies on system, utils)
- fix_engine_dll (shared librray; relies on fix_engine)
- fix_engine_test (executable; relies on fix_engine, GTest)

etc

All projects are built with /MD. In Unit Test executable it appears only once.

Original comment by Dmitriy....@gmail.com on 14 May 2010 at 9:48

[GoogleCodeExporter]

I'm in a very similar position to Dmitry.  (In fact, our project uses Google 
protocol
buffers which still default to /MD)

His patch above, allowing explicit setting of the CRT lib type would be of 
benefit to
us also.

I believe your original /msvc folder still has the two solutions - gtest.sln and
gtest-md.sln.  I suppose this would be achievable using CMake also, although I'd
prefer the explicit option within CMakeLists.txt

Original comment by fraser.hutchison@gmail.com on 14 May 2010 at 10:53

[GoogleCodeExporter]

I see your point. But in this case, the we need a slightly different semantics, 
with an option name such as 
GTEST_FORCE_SHARED_CRT.

Original comment by vladlosev on 14 May 2010 at 4:16

• Changed state: Started

[GoogleCodeExporter]

Implemented in revision 434.

Original comment by vladlosev on 18 May 2010 at 9:09

• Changed state: Fixed