MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015233CMakeCMakepublic2014-11-04 10:112016-06-10 14:31
ReporterBill Torpey 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSCentOSOS Version6.5
Product VersionCMake 2.8.12.1 
Target VersionFixed in Version 
Summary0015233: is there a way to force the use of bash for command execution?
DescriptionUnder Linux, cmake runs external commands (e.g., specified in add_custom_command) using sh. While sh resolves to bash, when invoked as sh bash does not support many features.

In particular, we need to:
- Specify LD_LIBRARY_PATH for a custom command (since it is being built as part of the build process, with a non-standard compiler)
- Specify ASAN_OPTIONS (since the custom commmand is being built w/clang+asan) to force it to return a zero return code.

The natural way to do this is to prefix the custom command:

LD_LIBRARY_PATH=... ASAN_OPTIONS=... command

While this is perfectly legal bash, sh fails with "No such file or directory"

It's possible to wrap the command in a shell script and execute that, but it would be much cleaner to specify the command directly in the CMakeLists.txt file.

FWIW, we don't care about portability -- our application is strictly Linux x86_64 -- we just use CMake as a superior alternative to autotools.

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-11-04 10:11Bill TorpeyNew Issue
2014-11-04 10:19Guillaume PapinNote Added: 0037152
2014-11-04 10:39Marcel LooseNote Added: 0037153
2014-11-04 11:14Bill TorpeyNote Added: 0037154
2014-11-04 11:27Brad KingNote Added: 0037156
2015-04-23 18:31Bill TorpeyNote Added: 0038592
2016-06-10 14:29Kitware RobotNote Added: 0042657
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0037152)
Guillaume Papin   
2014-11-04 10:19   
This doesn't answer your request but can't you just call 'env'?

env LD_LIBRARY_PATH=... ASAN_OPTIONS=... command
(0037153)
Marcel Loose   
2014-11-04 10:39   
Prefixing the command like you described is also perfectly legal in sh. So, there must be something else going wrong.
(0037154)
Bill Torpey   
2014-11-04 11:14   
Guillaume: With your suggestion the command runs, but the env variables are not in effect.

Marcel: Quite right! Fiddled with it some more and managed to get it going by changing around quoting.

Thanks!

Still: it would be helpful some times to force bash instead of sh -- they're not the same!
(0037156)
Brad King   
2014-11-04 11:27   
For reference, the code in CMake that tells the Makefile what shell to use is here:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalUnixMakefileGenerator3.cxx;hb=v3.0.2#l687 [^]

However, that is only relevant to the Makefile generators. A custom command specified by the project should also be able to work with the other generators for which the shell cannot be selected.

If you really want to run a bash script, then write one and run the file with bash:

  add_custom_command(... COMMAND bash ${CMAKE_CURRENT_SOURCE_DIR}/myscript.bash ...)

Also note that CMake 3.1 introduces "cmake -E env" as a cross-platform version of the POSIX "env" tool.
(0038592)
Bill Torpey   
2015-04-23 18:31   
Just an FYI -- we've taken the approach of writing a "link.sh" shell script and invoking that in the build (by setting new values for CMAKE_CXX_LINK_EXECUTABLE and CMAKE_CXX_CREATE_SHARED_LIBRARY).

(BTW, the purpose of this exercise is to unset LD_LIBRARY_PATH before calling the linker to ensure that only directories explicitly specified in the link command are searched).

That works, but it would be much cleaner if cmake would honor the value already set for SHELL, which in my environment is /bin/bash).
(0042657)
Kitware Robot   
2016-06-10 14:29   
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.