Commit Graph

258 Commits

Author SHA1 Message Date
Chris Bieneman 48eaa54151 [CMake] Ignore externalizing debuginfo for unit tests
If you externalize debug info for unit tests the test runner finds the mach-o inside the dsym bundle and tries to execute it as a test.

llvm-svn: 255056
2015-12-08 21:51:48 +00:00
Chris Bieneman ac6677ab8c [CMake] Fixing bots
CMake calls to set_property with APPEND string need to have a leading space.

llvm-svn: 254659
2015-12-03 22:55:36 +00:00
Chris Bieneman ccabd0e396 [CMake] set_target_properties doesn't append link flags
This fixes a bug introduced in r254627, and another occurance of the same bug in this file.

llvm-svn: 254657
2015-12-03 22:51:08 +00:00
Chris Bieneman bf2c4126ff [CMake] Add option LLVM_EXTERNALIZE_DEBUGINFO
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.

Reviewers: bogner, friss

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D15133

llvm-svn: 254627
2015-12-03 18:45:39 +00:00
Chris Bieneman 914742bb80 [CMake] export_executable_symbols also needs to add -rdynamic to the linker flags on Darwin
Without -rdynamic LLVM built with LTO fails to pass "check" due to loadable modules failing.

llvm-svn: 253944
2015-11-24 00:58:58 +00:00
Chris Bieneman 021f874c4f [CMake] Make llvm_install_library_symlink respect LLVM_LIBDIR_SUFFIX.
This is required to support multilib install targets, and addresses a regression introduced in r252093.

llvm-svn: 252749
2015-11-11 16:19:39 +00:00
Andrew Wilkins a4f370583d [cmake] move SONAME handling to llvm_add_library
Summary:
Move handling of the SONAME option from add_llvm_library
to llvm_add_library, so that it can be used in sub-projects.
In particular, this makes it possible to have consistently
named shared libraries for LLVM, Clang and LLDB.

Also, base the SONAME and symlinks on the output name
by extracting the OUTPUT_NAME property, rather than assuming
it is the same as the target name.

Reviewers: beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D14539

llvm-svn: 252669
2015-11-10 23:19:21 +00:00
Ramkumar Ramachandra cad135a95c AddLLVM: squelch CMP0007 by not adding empty elements to list
When configuring various llvm projects that use AddLLVM.cmake, this warning is
emitted many times, flooding the screen:

Policy CMP0007 is not set: list command no longer ignores empty elements.

The fix is removing an extra semicolon.

Differential Revision: http://reviews.llvm.org/D14339

llvm-svn: 252628
2015-11-10 18:26:34 +00:00
Chris Bieneman 5e96fe905b [CMake] Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig
Summary:
This change makes the CMake build system generate libraries for Linux and Darwin matching the makefile build system.

Linux libraries follow the pattern lib${name}.${MAJOR}.${MINOR}.so so that ldconfig won't pick it up incorrectly.

Darwin libraries are not versioned.

Note: On linux the non-versioned symlink is generated at install-time not build time. I plan to fix that eventually, but I expect that is good enough for the purposes of fixing this bug.

Reviewers: loladiro, tstellarAMD

Subscribers: axw, llvm-commits

Differential Revision: http://reviews.llvm.org/D13841

llvm-svn: 252093
2015-11-04 23:11:12 +00:00
Tom Stellard 18bf626cf7 llvm-config: Add --has-rtti option
Summary:
This prints NO if LLVM was built with -fno-rtti or an equivalent flag
and YES otherwise.  The reasons to add -has-rtti rather than adding -fno-rtti
to --cxxflags are:

1. Building LLVM with -fno-rtti does not always mean that client
applications need this flag.

2. Some compilers have a different flag for disabling rtti, and the
compiler being used to build LLVM may not be the compiler being used to
build the application.

Reviewers: echristo, chandlerc, beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D11849

llvm-svn: 252075
2015-11-04 20:57:43 +00:00
Manuel Klimek f80abb9ec7 Fix add_llvm_external_project.
r250835 unintentionally discarded the optional parameter to the
add_llvm_external_project() macro that may point to a path when the said
path is different from ${name}. This should fix it by passing ${ARGN} on
to add_llvm_subdirectory(). The problem manifests itself with e.g.
add_llvm_external_project(clang-tools-extra extra) from
clang/tools/CMakeLists.txt

Patch by Luchesar V. Iliev.

llvm-svn: 251001
2015-10-22 08:31:46 +00:00
Chris Bieneman 70997c3fb8 [CMake] Refactor subdirectory inclusion code to take a project name.
Summary:
This refactoring makes some of the code used to control including subdirectories parameterized so it can be re-used elsewhere.

Specifically I want to re-use this code in clang to be able to turn off specific tool subdirectories.

Reviewers: chapuni, filcab, bogner, Bigcheese

Subscribers: emaste, llvm-commits

Differential Revision: http://reviews.llvm.org/D13783

llvm-svn: 250835
2015-10-20 16:42:58 +00:00
Chris Bieneman 11a7160237 [CMake] Cleaning up and generalizing the LLVMInstallSymlink script so that it can be used for libraries too.
In order to resolve PR25059, we're going to need to be able to generate symlinks to libraries manually, so I need this code to be reusable.

llvm-svn: 250573
2015-10-16 23:17:13 +00:00
Reid Kleckner 066c8db347 Enable gtest SEH when building with clang-cl
Clang supports SEH well enough that this should work out of the box.  If
it doesn't, we'll hear about it.

llvm-svn: 249766
2015-10-08 22:44:39 +00:00
John Brawn c11ef2a89c [CMake] Make the bindir and libdir arguments to set_output_directory optional
When building a plugin against an installed LLVM toolchain using
add_llvm_loadable_module (in the documented manner) doesn't work as nothing sets
the *_OUTPUT_INTDIR variables causing an error when set_output_directory is
called. Making those arguments optional (causing the default output directory
to be used) fixes this.

Differential Revision: http://reviews.llvm.org/D13215

llvm-svn: 248911
2015-09-30 15:20:51 +00:00
John Brawn c23801d311 [CMake] Move the setting of LLVM_COMPILER_IS_GCC_COMPATIBLE to a separate file
Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining
the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to
use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used.
Move the setting of this variable into DetermineGCCCompatible and include that
from both AddLLVM and HandleLLVMStdlib.

Differential Revision: http://reviews.llvm.org/D13216

llvm-svn: 248798
2015-09-29 14:33:58 +00:00
Chris Bieneman 895d96a919 [CMake] Adding ALWAYS_GENERATE option to symlink utility functions.
This implements the behavior required for clang symlinks which should be always generated.

llvm-svn: 248039
2015-09-18 21:08:32 +00:00
Chris Bieneman 08249706cd [CMake] More cleanup of installing symlinks.
In order to support building clang out-of-tree the install_symlink script needs to be installed, and it needs to be found by searching the CMAKE_MODULE_PATH.

This change renames install_symlink -> LLVMInstallSymlink so it doesn't conflict with naming from other projects, and adds searching behavior in AddLLVM.cmake

llvm-svn: 248009
2015-09-18 17:39:58 +00:00
Chris Bieneman bff03b0982 [CMake] More refactoring of symlink creation.
This refactoring is to enable clang to re-use this code.

llvm-svn: 247850
2015-09-16 20:49:59 +00:00
Chris Bieneman bde7e4563e [CMake] Rename target->dest as per feedback from Chapuni on http://reviews.llvm.org/D12864
llvm-svn: 247658
2015-09-15 02:15:53 +00:00
Chris Bieneman 6d43afc7bd [CMake] Refactor and cleanup generating and installing symlinks to tools.
Summary: This change generalizes symlink generation and makes symlinks to tools obey LLVM_TOOLCHAIN_TOOLS. It makes it so that if you exclude llvm-ar from LLVM_TOOLCHAIN_TOOLS you don't end up with broken symlinks to llvm-lib and llvm-ranlib in your install.

Reviewers: bogner, chapuni, rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D12864

llvm-svn: 247632
2015-09-14 23:09:06 +00:00
Jordan Rose 85a22f8b6d [CMake] s/LLVM_SOURCE_DIR/LLVM_MAIN_SRC_DIR/
Fix-up for r247305 to use the right variable. There's another use of
LLVM_SOURCE_DIR in this file that is probably also questionable, but it's
for Windows so I'm going to leave it alone.

llvm-svn: 247311
2015-09-10 17:55:02 +00:00
Chris Bieneman 170fd9cb6e [CMake] Allow LLVM_TOOLCHAIN_TOOLS to be overridden
llvm-svn: 247306
2015-09-10 17:23:32 +00:00
Jordan Rose 3d75297056 [CMake] Fix Xcode build with LLVM_ENABLE_OBJLIB.
This amends chapuni's r246156 to handle an Xcode quirk, one even called out
in the CMake documentation:

    Some native build systems may not like targets that have only object files,
    so consider adding at least one real source file to any target that
    references $<TARGET_OBJECTS:objlib>.

I've limited the scope of this hack to Xcode for now.

llvm-svn: 247305
2015-09-10 17:18:51 +00:00
NAKAMURA Takumi bb7483dd77 [CMake][CMP0051] Avoid for user of objlib to use llvm_update_compile_flags().
$<TARGET_OBJECTS> shouldn't require compile flags. Flags are set in obj.${name}.

llvm-svn: 246984
2015-09-08 07:42:06 +00:00
Andrew Wilkins bb6d95fc3a [cmake] rework LLVM_LINK_LLVM_DYLIB option handling
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.

We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.

add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.

llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.

One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.

Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
 - link all tools and shared libraries to libLLVM if
   LLVM_LINK_LLVM_DYLIB is set
 - some way of explicitly *not* doing so for utilities
   and libLLVM itself
Suggestions for improvement here are particularly welcome.

Reviewers: beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D12590

llvm-svn: 246918
2015-09-05 08:27:33 +00:00
Andrew Wilkins 9211396d82 Enable linking tools, shared libraries against libLLVM
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM. 

1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
   executables and shared libraries against libLLVM. For this to work, it
   is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.

   It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
   we also default to OFF in this mode, or tools tend to misbehave (e.g.
   stdout may not flush on exit when output is buffered.)

   llvm-config and Tablegen do not use libLLVM, as they are dependencies of
   libLLVM.

2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
   Depending on which one is passed (default is component-libs), we link
   with the individual libraries or libLLVM respectively. We pass in dylib
   when LLVM_LINK_LLVM_DYLIB is ON.

3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
   actually export all. Don't strip leading underscore from symbols on Linux,
   and make sure we get all exported symbols and weak-with-default symbols
   ("W" in nm output). Without these changes, passes won't load because
   the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
   found.

Testing:
 - Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
 - Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
   never had much success with LLDB tests, and llgoi is currently broken
   so check-llgo fails for an unrelated reason.
 - Ran "lldb" to ensure it loads.

Reviewers: chandlerc, beanz, pcc, rnk

Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits

Differential Revision: http://reviews.llvm.org/D12488

llvm-svn: 246527
2015-09-01 03:14:31 +00:00
NAKAMURA Takumi b5288ba9d1 [CMake] Fix build on MSVC in r246156.
add_windows_version_resource_file() affects ALL_FILES. OBJLIB shouldn't have *.obj as SOURCES.

llvm-svn: 246241
2015-08-28 00:36:58 +00:00
NAKAMURA Takumi e6bc093b42 [CMake] OBJLIB-ize *-tblgen.
This improves dependency chain of;

  (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen)

with;

  (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen)

llvm-svn: 246156
2015-08-27 16:10:47 +00:00
NAKAMURA Takumi 6fa8532041 [CMake] add_llvm_external_project: Just warn about nonexistent directories.
These entries were generated accidentally.

llvm-svn: 245783
2015-08-22 05:11:02 +00:00
NAKAMURA Takumi 04e2da526f [CMake] Make LLVM_EXTERNAL_*_SOURCE_DIR consistent against older buildsites.
If corresponding in-tree subdirectory exists, just ignore LLVM_EXTERNAL* stuff.
Otherwise, set LLVM_TOOL_*_BUILD ON/OFF properly according to LLVM_EXTERNAL_*.

This makes easier to walk among old revisions *without* deleteing CMakeCache.txt.

Before r242059, LLVM_EXTERNAL_* was working like;

  if(EXISTS ${*_SOURCE_DIR}/CMakeLists.txt)
    set(*_BUILD ON CACHE)
    if(*_BUILD is ON)
      add_subdirectory(*_SOURCE_DIR)
    endif()
  endif()

llvm-svn: 245782
2015-08-22 04:53:52 +00:00
Reid Kleckner 7752db61cc Revert "[cmake] Add helper for finding potentially external projects"
This reverts commit r244633.

We aren't going to be able to use it because the compiler-rt build can
be built standalone without an LLVM source dir *or* an installed copy of
LLVM.

llvm-svn: 244648
2015-08-11 19:02:57 +00:00
Reid Kleckner de98228fab [cmake] Add helper for finding potentially external projects
I plan to use this from compiler-rt, but it's useful for any LLVM
project that depends on more than just LLVM.

llvm-svn: 244633
2015-08-11 17:16:35 +00:00
Chris Bieneman 19d42692e7 [CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be explicitly specified.
One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included.

llvm-svn: 242793
2015-07-21 15:53:09 +00:00
Andrew Wilkins 6c1bfa93f5 [cmake] pass GO_EXECUTABLE to llgo-go
Summary:
When calling llgo-go from the llvm_add_go_executable
cmake function, specify $GO_EXECUTABLE as the go
command to call. Without this, llgo-go searches $PATH
which may be inconsistent with $GO_EXECUTABLE.

Reviewers: pcc

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D11290

llvm-svn: 242749
2015-07-21 00:46:23 +00:00
Chris Bieneman 077f3fe1a1 [CMake] Fixing inconsistency caused by copy-pasta.
This will actually fix the PR 24194.

llvm-svn: 242748
2015-07-21 00:44:47 +00:00
Chris Bieneman 95ba62c91a [CMake] Fixing a problem with external projects that aren't getting enabled properly.
This should address PR 24194, and some builedbot failures.

llvm-svn: 242746
2015-07-21 00:39:53 +00:00
Chris Bieneman 580d8159d5 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Re-landing r242059 which re-landed r241621... I'm really bad at this.

Summary (r242059):
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.

Summary (r241621):
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 242705
2015-07-20 20:36:06 +00:00
NAKAMURA Takumi ae5d78d722 [CMake] Unbreak add_llvm_external_project when external projects are specified.
LLVM_EXTERNAL_*_SOURCE_DIR is reset as PATH with set(CACHE PATH).
Then the CACHE PATH variable, LLVM_EXTERNAL_*_SOURCE_DIR, is normalized as
${CMAKE_SOURCE_DIR}/${path_var} if ${path_var} is relative.

llvm-svn: 242120
2015-07-14 05:12:53 +00:00
Chris Bieneman d36f614e20 [CMake] Forgot to quote the first part of STREQUAL.
llvm-svn: 242103
2015-07-14 01:19:07 +00:00
Chris Bieneman 3da1b6e260 [CMake] We shouldn't be storing values in the cache unless they actually need CMake cache behavior.
add_llvm_external_project puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache even if it is just the in-tree default path. This causes all sorts of oddness, and makes it so that I can't change the behavior of this variable.

This patch never puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache. It will only end up in the cache if it is specified on the command line, which is the correct behavior.

There is also a temporary change to remove non-default values from the cache if they are already present. This should have the impact of cleaning out unncecissary values from the caches on the buildbots and people's local build directories. This part of the change is marked with a TODO and can be removed in a few days.

llvm-svn: 242102
2015-07-14 01:17:43 +00:00
Chris Bieneman 86b1fd77e6 Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working."
Reverting r242059 because it broke some bots. I'm attempting to reproduce the failures now.

llvm-svn: 242060
2015-07-13 20:30:58 +00:00
Chris Bieneman 8ac6d119b7 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Summary:
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.

Original Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 242059
2015-07-13 20:23:15 +00:00
NAKAMURA Takumi 58843eede5 Revert r241621, "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working."
It broke the build that relies on LLVM_EXTERNAL_CLANG_*.

llvm-svn: 241663
2015-07-08 02:35:43 +00:00
Chris Bieneman 3765588f65 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables
* removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Reviewers: bogner, samsonov, chapuni, beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 241621
2015-07-07 20:24:55 +00:00
NAKAMURA Takumi 3eb06667bd [CMake] add_llvm_symbol_exports: Use Python oneliner instead of "cmd.exe /c type" to generate *.def.
llvm-svn: 241402
2015-07-05 08:56:38 +00:00
Dan Liew 80189d2d15 Fix bug #23967. The gtest and gtest_main targets were exported into the
CMake files and should not be by both build systems and also the targets
were also installed by the CMake build system which they should not be.

The problem was that

- the CMake build of LLVM installs and exports the gtest library
targets. We should not being doing this, these are not part of LLVM.

- the Autoconf/Makefile build of LLVM still had gtest libraries in the
installed LLVMConfig.cmake.

These problems would cause problems for an external project because when
calling llvm_map_components_to_libnames(XXX all) ${XXX} would to contain
LLVM's internal gtest libraries.

llvm-svn: 240981
2015-06-29 18:45:56 +00:00
Rafael Espindola c32ed570bf Support Solaris unused sections' gc link syntax.
It is not clear if this would work or not with LLVM_NO_DEAD_STRIP
binaries, so be conservative for now.

Patch by Xan López.

llvm-svn: 240287
2015-06-22 15:06:17 +00:00
Rafael Espindola 95fa3463cc Do not pass optimization flags to Solaris' linker.
It is not supported.

Patch by Xan López.

llvm-svn: 240276
2015-06-22 12:41:52 +00:00
Rafael Espindola ec1d069d70 Use right syntax to pass version script to Solaris' ld.
Patch by Xan Lopez!

llvm-svn: 240275
2015-06-22 12:34:54 +00:00