I'm working on Ubuntu 14.04 with ROS Indigo and I need to use Geometry Tools Wild Magic 5 for developing a package.
I have exported the path to Wild Magic folder as an environment variable by modifying .bashrc as follows:
export WM5_PATH=/home/user/catkin_ws/src/GeometricTools/WildMagic5/SDK
This is done to specify locations of header files in the CMakeLists.txt file of the package I'm coding:
include_directories(
include
$ENV{WM5_PATH}/Include/
)
Previously, in the same cmake file I check if the environmental variable is correctly set:
if (NOT DEFINED ENV{WM5_PATH})
MESSAGE (FATAL_ERROR "Wild Magic Engine 5.14 missing")
endif()
Now, while building the package using catkin build the environment variable is not found (the if above is entered). But by using printenv in the terminal I can see that the environment variable WM5_PATH is actually there.
How could I solve this problem?
I've just given your example a try and it works fine in my Ubuntu bash shell.
# export WM5_PATH=/home/user/catkin_ws/src/GeometricTools/WildMagic5/SDK
# cmake ..
-- Configuring done
-- Generating done
-- Build files have been written to: ...
So I suspect your cmake executable runs in another environment (e.g. an IDE).
To check what your CMake does see as an environment you could add the following to your CMakeLists.txt:
execute_process(
COMMAND ${CMAKE_COMMAND} -E environment
)
Reference
How to retrieve a user environment variable in CMake (Windows)
Related
I'm using CLion IDE, Cmake and trying to write Hello world using CERN ROOT library.
CMakeLists.txt:
message(STATUS $ENV{ROOTSYS})
~/.bashrc:
export ROOTSYS="$HOME/tools/root-build/"
During build in CLion $ENV{ROOTSYS} is empty by some reason. But $ENV{PATH} returns correct $PATH.
What I did wrong?
Variables from .bashrc aren't passed.
Go to File -> Settings -> Build,Execution,Deployment
For Clion 2017.2+
For old Clion
Click Pass system and...
If you want to read environment variable in C++ runtime e.g. using std::getenv then
it won't work as we added environment variable for CMAKE not for runtime.
You can add such variable:
And then in your code:
std::filesystem::path getRootConfigPath()
{
// std::getenv can return nullptr and this is why we CAN'T assign it directly to std::string
const char* path = std::getenv("TEST_CONFIG_DIR");
gcpp::exception::fail_if_true(
path == nullptr, WHERE_IN_FILE, "No such environment variable: ${TEST_CONFIG_DIR}");
gcpp::exception::fail_if_true(std::string_view{path}.empty(),
WHERE_IN_FILE,
"Missing ${TEST_CONFIG_DIR} environment variable");
const std::filesystem::path testConfigDir{path};
gcpp::exception::fail_if_false(std::filesystem::exists(testConfigDir) &&
std::filesystem::is_directory(testConfigDir),
WHERE_IN_FILE,
"Invalid ${TEST_CONFIG_DIR} dir:" + testConfigDir.string());
return testConfigDir;
}
Source of gcpp::exception::fail_if_true
Other way to do this in more friendly way when running unit tests is add this variable to template.
So whenever you click:
Such variable will be there already.
From CLion developers FAQ:
Q: How to pass environment variables and parameters to CMake in CLion?
A: The best way is to use Preferences/Settings | Build, Execution, Deployment | CMake dialog.
As for .bashrc file, it is only used by bash. CLion doesn't need to use bash for run configuration process.
On Ubuntu 17.04, you can set a permanent environment variable by modifying
/etc/enviornment
[I assume you can do this in other versions of Linux, but I provide the version of the system that I am using.]
For example, I am compiling test cases that assume that ${GOOGLE_MOCK} has been set. I added the following to my /etc/environment file, and now I don't have to rewrite all of my CMakeLists.txt files:
GOOGLE_MOCK=/usr/local/src/googletest/googlemock
GOOGLE_TEST_HOME=/usr/local/src/googletest/googletest
Clion just became much more useable.
One thing you can check is the .gdbinit. Clion on Linux will invoke the gdb, which will read in the .gdbinit. I happen to have set environment LD_LIBRARY_PATH xxx in my .gdbinit file, which will override whatever you set LD_LIBRARY_PATH from shell, whether through direct export or through .bashrc, or from CLion environment variable panel.
Hope this helps.
Source your variables in .profile not .bashrc
I try to run a deployment script using KDE Neon. I have started the script manually from bash and I got an error qmake would be not found.
When trying to run qmake directly from the bash I get the following error:
$ qmake -v
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory
That bin folder is almost empty and contains no qmake. In the path /usr/lib/x86_64-linux-gnu/qt5/bin/ a full Qt installation can be found but no qmake as well. /usr/bin/qmake obviously is a link that is pointing to the missing /usr/lib/x86_64-linux-gnu/qt4/bin/qmake.
qmake works fine when using Qt Creator. The binary used by Qt Creator is /home/<user>/Qt/5.10.0/gcc_64/bin/qmake.
Obviously the /usr/... Qt installations aren't complete. First I thought about how to complete the installations and how to switch from Qt4 to Qt5. However Qt Creator obviously is able to use its own /home/... located Qt environment anyway and I would like to use it too when running a script outside Qt Creator.
Is there a way I can start scripts from bash using the same Qt environment as Qt Creator (without modifying the OS configuration)?
QtCreator itself only modifies the environemt, i.e. it sets
export PATH="/home/<user>/Qt/5.10.0/gcc_64/bin:$PATH"
export QTDIR="/home/<user>/Qt/5.10.0/gcc_64"
This can be verified by checking the "Build Environment" section in the "Projects" tab. When checking the environment for the run configuration there is one more that is needed for the compiled applications to find the correct .so files (The build env. is used to run build tools. The run env. is used to run the compiled application).
export LD_LIBRARY_PATH="/home/<user>/Qt/5.10.0/gcc_64/lib:$LD_LIBRARY_PATH"
So in order to easily use qmake/... from the command line, just create a script that sets these (and possibly others you defined for your build in QtCreator) and source it before compiling and it should work.
source ~/qt-home-init.sh
qmake ...
I use qtcreator to build my project. When I use Terminal to open qtcreator and build the project, it works. However, when I use Desktop to Open qtcreator, it shows that can't not found the library.
Accurately, I add the libs to environment variable so that I can use it Makefile to build the project in Terminal.
So I am confused if the environment variable is different between Terminal and Desktop.
The qt project file is process.pro.
Oh, we found that when we run .desktop file, it does not contain bash environment. So adding bash -i -c in [Exec] can solve it.
I use swig from my within Android.mk. I reference it directly relying on the $PATH variable to contain the path to it's executable.
The issue is that the $PATH variable is different depending on where the android-ndk tool is run from.
Background
In my Android.mk file:
# some stuff ...
#echo "$(PATH)"
swig # swig parameters here...
# more stuff ...
From the terminal, we see the system path includes the path to swig:
which swig
/usr/local/bin/swig
echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
Issue
When the android-ndk is run from within Android Studio I get the following for PATH (note: it's missing the swig path):
/usr/bin:/bin:/usr/sbin:/sbin
This causes my build to fail because "swig" isn't recognised:
make: swig: Command not found
However, if I run the android-ndk directly from the terminal, then the PATH used is the same as my system path and the build works fine:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
Bad solution
Yes, I could add the path manually to my Android.mk file:
export PATH:=/usr/local/bin/:$(PATH)
However, I'd prefer not to define specific paths for my machine knowing that the whole team uses this file.
Question
I'd prefer the Android.mk file to use my systems PATH instead.
Any ideas how to do this?
Thanks!
The thing in my opinion is that environment variables may be different whether the process is launched from terminal or from the GUI (launchpad, spotlight, ...).
The former would use PATH as set in bashrc (or other shell related startup files) while the other will not.
I think you might find interesting information on how to change the environment variables for the launch deamon in the following question:
Setting environment variables in OS X?
I have a script that sets all variables needed for the cross-compilation. Here is just part of it :
export CONFIG_SITE=~/workspace/eldk-5.4/powerpc/site-config-powerpc-linux
export CC="powerpc-linux-gcc -m32 -mhard-float --sysroot=~/workspace/eldk-5.4/powerpc/sysroots/powerpc-linux"
export CXX="powerpc-linux-g++ -m32 -mhard-float --sysroot=~/workspace/eldk-5.4/powerpc/sysroots/powerpc-linux"
export CPP="powerpc-linux-gcc -E -m32 -mhard-float --sysroot=~/workspace/eldk-5.4/powerpc/sysroots/powerpc-linux"
export AS="powerpc-linux-as "
export LD="powerpc-linux-ld --sysroot=~/workspace/eldk-5.4/powerpc/sysroots/powerpc-linux"
export GDB=powerpc-linux-gdb
If I do source environment-setup-powerpc-linux, all environment variables are imported into the current shell session, and I can compile my example.
Is it possible to import these variables in cmake? If yes, how?
A bit more details :
I am using ELDK v 5.4, and it's install script generates a script which sets all environment variables
I found this tutorial, which explains how to manually set for cross-compilation, but not how to use the script, which sets everything
if I call the script before setting cmake, all works fine, and I can cross-compile, but I'd like that cmake calls the script
Reading through the cmake quick start, you can specify variable on a command line:
cmake -DVARIABLE1=value1 -DVARIABLE2=value2 ...
Otherwise, set command in the cmake script is probably what you want, see the reference manual. To set the environment variable PATH, do:
set(ENV{PATH} "/home/martink")
To set normal variable, do:
set(variable "value")
Not sure which ones you have to set, probably the environment ones.
That said, setting environment variable prior to calling cmake is often the easiest solution to solve the problem. If you want a cross-platform way to do this that doesn't depend on the syntax of a specific shell to set environment variables, there is the cmake -E env command.
The only way to set a compiler and flags to do cross-compilation reliably with CMake is with a toolchain-file as done in the tutorial you have found.
When we faced the same issue you have (a toolkit which produces a script so set the compile-environment) we changed the toolkit in a way that it produces a toolchain-file along with the script.
In reality a cmake-toolchain-file does not change that often. The basic flags used for the target are fixed quite early in a project - normally. And with CMake's CMAKE_BUILD_TYPE you can switch between Debug and Release compilations without changing the toolchain-file.
If you have different targets to support, create different toolchain and use the out-of-source-build with CMake.
EDIT: One thing you could do is to invoke cmake with the -D-argument setting the variables you want to and having sourced your script before:
source environment-setup-powerpc-linux
cmake -DCMAKE_C_COMPILER=$CC -DCMAKE_CXX_COMPILER=$CXX etc
The result will be identical as to having used a toolchain-file.