I use environment modules to dynamically set up my development environment in WSL / ubuntu, which means that I try to only have a very minimum set of tools installed in my /usr/bin directory with the rest being loaded at runtime.
This does, however, then also mean that I have to load the modules before I do any compilation (for example "module load CMake GCC"). Is there an option in CLion that lets me pass commands to be executed in WSL before CMake is invoked? Or is there a way to let CLion connect to an existent WSL session which has been pre-configured?
Related
Is it possible to have CMake “export an environment variable” such as LD_PRELOAD before invoking the compiler/linker, like you could in a shell?
I am using an old 32-bit cross-compiler in WSL2. The source files are on Windows filesystem mounted into WSL, where the inodes are 64-bit thus not supported and cannot be read by the compiler.
cc1plus: error: /mydir/.../source.cpp: Value too large for defined data type
I followed instructions from The 64 bit inode problem, and built inode64.so and manually verified it works with the 32-bit cross-compiler in a shell:
export LD_PRELOAD=/mydir/.../inode64.so
arm-fsl-linux-gnueabi-g++ source.cpp
My question is, since I am building the project with CMake, how can I invoke ONLY the 32-bit compiler/linker from CMake with
LD_PRELOAD=/mydir/.../inode64.so
In my project build script, I tried export LD_PRELOAD before calling cmake, but it didn't work (because the 32-bit .so doesn't work with native 64-bit cmake tools?)
cmake ./
export LD_PRELOAD=/mydir/.../inode64.so
make install
ERROR: ld.so: object '/mydir/.../inode64.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Set the variable CMAKE_CXX_COMPILER_LAUNCHER to env LD_PRELOAD=whatever.so. This will use the env command to launch the compiler.
The variable is used to initialize target properties, and of 3.25 supports generator expressions, so if you are using multiple compilers in the same build, you can wrap the env command in a test for compiler version or compiler name.
If instead you are using this compiler for all c++ builds in a particular configuration, just conditionally set the variable:
if(MY_CROSS_COMPILING_32_BIT)
set(CMAKE_CXX_COMPILER_LAUNCHER env LD_PRELOAD=whatever.so)
endif()
so I just downloaded wslusing the wsl --install command using PowerShell
now I'm trying to connect it to Clion which works
i cant add images so here is a link to it
but when i'm tying to build the project i get this error
"CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.20 or higher is required. You are running version 3.16.3"
my cmake file:
cmake_minimum_required(VERSION 3.20)
project(ex2 C)
set(CMAKE_C_STANDARD 99)
add_executable(ex2
ex2.c ex2.h
main1.c
main2.c)
i tried updating wsl using wsl --update (in powershell)
The CMake installation inside the WSL is used. Unfortunately currently snap doesn't seem to be available in WSL, but installing the latest CMake version isn't too complicated nonetheless:
(optional) uninstall the old cmake installation in WSL; personally I don't see any benefit in multiple CMake installations, but there may be valid reasons for this. Most likely this will just makes the use of cmake more complex, since you need to remember which cmake version is used.
Download the appropriate cmake version from the cmake website ( https://cmake.org/download/ ). The version to choose is the tar.gz file under binary distributions for the x86_64 target. To get version 3.21.4 (currently the latest release), you can download the file from https://github.com/Kitware/CMake/releases/download/v3.21.4/cmake-3.21.4-linux-x86_64.tar.gz (Identical to the link on the CMake download page).
Unpack the archive from WSL. Navigate to the directory where you want the cmake installation to recide. This will add the cmake-3.21.4-linux-x86_64 directory containing all the files required to work with cmake to the current working directory. Let's assume you want to add the cmake files to the /opt directory. Furthermore let's assume the windows user name to be fabian, C: to be the primary hard drive and the download to be saved to the Downloads directory in the user directory:
cd /opt
tar -xf /mnt/c/Users/fabian/Downloads/cmake-3.21.4-linux-x86_64.tar.gz
(optional) make CMake available without specifying the path; this could be done as described here: https://unix.stackexchange.com/questions/3809/how-can-i-make-a-program-executable-from-everywhere ; don't do this, if an existing cmake installation is already available in the command line assuming you did install cmake to /opt, the cmake binary recides at /opt/cmake-3.21.4-linux-x86_64/bin
You should now be able to use cmake specifying either the full path to the executable (/opt/cmake-3.21.4-linux-x86_64/bin/cmake assuming you used the /opt directory) or directly via a command after opening the WLS commandline again (provided you followed step 4).
Now the only thing left to do should be telling CLion about the location of the cmake executable. Note that I haven't tested this, since I don't use this IDE. It's working fine using Visual Studio Code though...
I am trying to move from an own written tool to cmake for Windows to simplify our build environment.
We have a tool in the build process that requires to have set environment variables. I would like to set them with cmake but don't know how. What I have tried:
set(ENV{MYENVVAR} "My-Content")
I would expect that I can read this environment variable again with
message($ENV{MYENVVAR})
But this does not work. Even setting a variable before invoking cmake (instead of setting it in cmake) does not help, I cant read the variable in cmake.
What do I do wrong?
Edit:
I do invoke cmake again after changing CMakeLists.exe.
I do set environment variables with set MYENVVAR=My-Content in Windows cmd.exe and then invoke cmake from exactly this console.
cmake is version 3.20.0 for Windows.
You're going to need to produce a minimal, reproducible example. Here's my best attempt based on your question and unfortunately, the best I can say is "works for me":
alex#alex-ubuntu:~$ export MYENVVAR=FooBarBaz
alex#alex-ubuntu:~$ cat test.cmake
cmake_minimum_required(VERSION 3.20)
message($ENV{MYENVVAR})
set(ENV{MYENVVAR} "My-Content")
message($ENV{MYENVVAR})
alex#alex-ubuntu:~$ cmake -P test.cmake
FooBarBaz
My-Content
alex#alex-ubuntu:~$ echo $MYENVVAR
FooBarBaz
So CMake can both read the environment variable and write to it in-process, but it does not affect the controlling process's (in this case bash; in your case cmd.exe) environment.
I downloaded CustusX from the homepage and tried to follow the build instructions. (with ./cxInstaller.py --full --all -t RelWithDebInfo as last command. That went smoothly on Kubuntu 14.04.
Now with everything checked out and available on the harddisk I tried to set up a project that such that I can do some debugging from within an IDE eg. qtcreator or eclipse. I searched the documentation but didn't find it there.
I tried to point cmake-gui at /[...]/custusx/CX/CX, chose Eclipse CDT4 - Ninja and tried to configure. But it fails since it cannot find FindEigen.cmake:
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
Could NOT find Eigen (missing: EIGEN_INCLUDE_DIR EIGEN_VERSION_OK)
(Required is at least version "2.91.0")
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
CMake/FindEigen.cmake:76 (find_package_handle_standard_args)
CMake/cxInitializeLibraries.cmake:273 (find_package)
source/CMakeLists.txt:11 (cx_initialize_Eigen)`
I see there is a FindEigen.cmake in the CMake directory, but setting the CMAKE_MODULE_PATH didn't help either.
QtCreator didn't work either as it experiences the same problems parsing the CMake files when pointed at CMakeLists.txt at custusx/CX/CX
So, the question is how to get a running setup in an IDE preferable qtcreator or eclipse for developing custusx plugins?
CustusX is configured using the superbuild cxInstaller.py. As part of this build, cmake is invoked with parameters:
cmake arguments source_folder
An example when located in the build folder /home/cas/cx/CX/build_Release:
cmake -G"Eclipse CDT4 - Ninja" -DCMAKE_BUILD_TYPE:STRING=Release -DEIGEN_INCLUDE_DIR:PATH=/home/cas/cx/eigen/eigen -DCTK_DIR:PATH=/home/cas/cx/CTK/build_Release -DOpenCV_DIR:PATH=/home/cas/cx/OpenCV/build_Release ...more arguments omitted... /home/cas/cx/CX/CX
This command can be found by looking through the console output of cxInstaller.py, under the heading == configure CustusX ==. Once the superbuild is run once, you can start working with cmake-gui, QtCreator or Eclipse:
When using cmake-gui, set "Where to build the binaries" to your build folder. This will automatally cause the existing cmake configuration to be loaded. In your case, cmake-gui probably tried to configure from scratch, without arguments.
When using QtCreator, first open the root CustusX CMakeLists.txt file. This leads you to the "Configure Project" page. The cmake configuration must be added manually: Set the location of the build folder, then configure, which fails. Then, in "Project->Build Settings->CMake arguments", paste in all arguments that the superbuild (cxInstaller.py) sent to cmake, i.e. the cmake command line excluding cmake and source folder. If using ninja, you might have to configure that as well.
It seems like the current version of QtCreator (3.0.1, Ubuntu 14.04) do not read the cmake configuration of a project, requiring the procedure described above. This was not necessary with the version shipped with Ubuntu 12.04.
When using Eclipse, use "Import", then "General->Existing Projects into Workspace", select CX as root directory, when CustusX should appear as a project that can be imported directly (Caution: If you prevously configured using QtCreator, the Eclipse project files will have been deleted. Run the superbuild again)
How to set up QtCreator 3.0.1 (Not needed for other versions of QtCreator) on Ubuntu 14.04 for CustusX:
Get CMake arguments (with minimal output):
./install/cxInstaller.py --configure -t RelWithDebInfo CustusX
Search through the output for the (long) line starting with cmake and ending with ...cx/CX/CX
Paste in these arguments in Project->Build Settings->CMake arguments
I had been using CMake without problems when I discovered my Ubuntu was installed as 32-bit even though my processor is actually 64-bit. Whoops.
I reinstalled Ubuntu and the various dev packages I was using. Now when I run make I get errors like this:
[ 1%] make[2]: *** No rule to make target `/usr/lib/i386-linux-gnu/libQtGui.so', needed by `/home...
/usr/lib/i386-linux-gnu/libQtGui.so` doesn't exist but /usr/lib/x86_64-linux-gnu/libQtGui.so does.
I have run ccmake to reconfigure and regenerate the makefile and run make clean but it's still looking for 64-bit libraries. If I expand the ccmake options I can see the 32-bit library path in various variables.
I have created a new build directory and run ccmake from scratch and this works but now I have to remember all the nondefault settings I put in and reproduce them in the new build environment.
I'd rather just "upgrade" the CMake setup to 64-bit, preserving my own flags. Is this possible?
Start with a new CMake cache:
rm CMakeCache.txt
If you don't like removing your Cmake cache, you can edit it and search-and-replace to modify the paths of libraries.