Notes
(0033097) Craig Scott (reporter) 2013-05-20 00:08	In case it's useful to others, note that 0006103 also contains a helpful workaround for this issue, although the code presented there needed to be changed slightly to work for me. The corrected version of that code is as follows: install(CODE "EXECUTE_PROCESS(COMMAND ${CMAKE_STRIP} --strip-unneeded \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin/${target})") 0006103 is closed, so unfortunately I cannot add the above correction to that bug report.

(0033394) Alex Neundorf (developer) 2013-06-27 15:21	So your actual targets are built in subprojects using ExternalProject. Do the subprojects have an install phase, i.e. are they installed during building ? This is the point where the stripping should happen. I didn't check, but I'm quite sure that only targets, i.e. files installed via install(TARGETS) are stripped. In your case the outer project does not install targets, so they are not stripped.

(0033396) Craig Scott (reporter) 2013-06-27 19:18	Targets are built in the subprojects and they are installed from there too. They are not being stripped as a result of the subproject install steps.

(0033401) Alex Neundorf (developer) 2013-06-28 15:12	Not sure we are talking about the same "install". Do they external_project_add() calls use an INSTALL step ? If that's the case, after they have been installed internally during the build, they are installed from the super-project via install(PROGRAMS ...) from their internal install location to their final install location ? Are the subprojects also using cmake ? If so, can you try to make them use the install/strip target for the internal install step ? Then they will be stripped when the final install is done.

(0033412) Craig Scott (reporter) 2013-06-30 19:56	Sorry, my last comment was ambiguous. The targets are installed by the subprojects to a common directory and this is generally using the default install behaviour of external_project_add() (ie relying on "make install" or its equivalent being called). This is where the stripping should happen but isn't, if I understand you correctly. We then have another subproject which builds a package by pulling files from that common directory (the subproject is also implemented via external_project_add()). This last packaging subproject uses install(...) too, but not in the usual way. This packaging subproject is not meant to install anywhere, but rather it needs to generate packages via a "make package" step. To achieve this, we've used the following as part of the external_project_add() call: INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} INSTALL_COMMAND cd ${CMAKE_CURRENT_BINARY_DIR} STEP_TARGETS configure build package This has the effect of making the install step a no-op and adding a "package" step to the set of steps performed automatically, which is the behaviour we need. Within this packaging subproject, we use install(PROGRAMS...) and install(FILES...), but your earlier comments suggest that these last two install methods are not expected to do any stripping. I'd argue that the install(PROGRAMS...) form should do stripping, but that's more a side issue. To make this discussion simpler, let's just consider all projects and subprojects to be using CMake. I have one subproject that doesn't, but the behaviour I'm seeing is also present for the subprojects that are CMake-based and it's those that I'm primarily interested in here.

(0033413) Craig Scott (reporter) 2013-06-30 20:02	FWIW, ideally we'd like the install to the common directory to not strip, since we sometimes need to run binaries from there during development, hence having debug info still present is useful. The creation of the package is where we would expect/want the stripping to be performed. This is where we expected CPack to do the stripping automatically and it does try to, it's just that the strip implementations on different linux distributions varies (as explained in the original issue description). If I recall correctly, CPack doesn't actually look at how the files got into the package when it decides which ones to try to strip - I think it just goes through each file in the package and looks at what type of file each one is, but the precise details of what happens have slipped from my memory now.

(0042285) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2013-05-19 22:41	Craig Scott	New Issue
2013-05-20 00:08	Craig Scott	Note Added: 0033097
2013-05-20 08:54	Brad King	Assigned To	=> Alex Neundorf
2013-05-20 08:54	Brad King	Status	new => assigned
2013-06-27 15:21	Alex Neundorf	Note Added: 0033394
2013-06-27 19:18	Craig Scott	Note Added: 0033396
2013-06-28 15:12	Alex Neundorf	Note Added: 0033401
2013-06-30 19:56	Craig Scott	Note Added: 0033412
2013-06-30 20:02	Craig Scott	Note Added: 0033413
2016-06-10 14:28	Kitware Robot	Note Added: 0042285
2016-06-10 14:28	Kitware Robot	Status	assigned => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships