I'm using Pybind11 to make C++/Python modules and apparently the output .DLLs need to be in the PYTHONPATH for the module to be imported (appending to sys.path does not work).
I'm using CMake variants to set various builds, and that makes separate output directories per variant.
I'm at a loss to find a way to set the PYTHONPATH environment variable in the integrated terminals (and jupyter notebooks) based on my chosen variant.
Any suggestions?
"terminal.integrated.env.windows": {
"PYTHONPATH": "${workspaceRoot}\\build\\${variant:platform}"
},
does not work (it doesn't seem to substitute ${variant:platform}).
in the .env file, neither ${workspaceRoot} nor ${variant:platform} seem to be available
Related
I am investigating how feasible would it be to switch to Visual Studio Code with larger and more complex projects in C++ with cmake and have hit the wall regarding environmental variables.
Some projects I'm dealing with require a complex structure of interconnected environmental variables, currently this is solved by mostly manual build in bash prompt
$ source envSetupFile
$ mkdir build && cd build
$ cmake .. && make -j $(nproc)
where the envSetupFile contains a lot of different variables, most cases related to toolchain and some specific settings. When those are just plain strings, everything works fine, however there are many cases of variables depending on another one, for example something like (in bash)
export PATH=/opt/custom/lib: $PATH
export ROOT=/some/path
export BIN=$ROOT/bin
export LIB=$ROOT/lib
what I did
I installed the c/c++ extension package along with CMake and CMakeTools packages plus EditorConfig for VS Code
and added custom lines to the visual studio config in the workspace:
/projectpath/.vscode/cmake-kits.json where I set the environmental variables, but while I can set (and verify) directly defined work, any that requires value of another fails completely.
example:
"environmentVariables":{
"POTATO": "aaa",
"CARROT": "bbb",
"CABAGE": "${POTATO}/${CARROT}"
}
I'd expect that afterwards when running cmake which references ${CABAGE} would resolve it as aaa/bbb, but instead of it it takes them as string literals and produces ${POTATO}/${CARROT} as ouptut
I must confess I'm a bit surprised by no trace of such use case in documentation or examples I've seen so far. Perhaps someone could lend a hand? (I'm running VisualStudio Code Version: 1.36.1 on ubuntu 16.04)
I am defining custom tasks using the tasks.json file in MS Visual Studio Code. It is great that there are a load of predefined variables available such as ${relativeFile} or ${fileBasename} available as defined in the Variables Reference, but the values of these are (on my Windows platform) always Windows-specific, such as:
${relativeFile} resolves to (say) c:\Users\SHarrop\Desktop\dev\myFile.txt
This is not helpful when I have set my default shell to be bash (expecting forward slashes). I feel there must be a better answer than "If you use pre-populated variables in your tasks on a Windows platform, then you need to use the Windows shell". Similarly I might be passing such variables as arguments into scripts that expect Unix-style paths.
Is there any way of getting Unix-flavored values on a Windows platform?
Thanks!
I am creating a Chocolatey package for internal team usage. (In this case, the package is for Microsoft's windows debuggers.)
Windows Debuggers contains two folders, one for 32-bit x86 executables and an x64 folder for 64-bit executables.
The executable names are identical.
x86\adplus.exe
x64\adplus.exe
After installation it looks like the shim created by Chocolatey is indeed starting one of the adplus instances successfully. But sometimes I need the 32-bit version and sometimes I need the 64-bit version.
So here is the question: When there are two identically named executables in different directories, how do I tell Chocolately to create different shims for the executables in each directory?
The short answer is that you can't have two identically named shims in the Chocolatey shim folder ($env:ChocolateyInstall\bin).
A limitation of Windows for a directory is that each file/folder must be a unique name. This is what you are running into. Shims get dropped into the $env:ChocolateyInstall\bin folder, which puts them on the PATH automatically because $env:ChocolateyInstall\bin is on the PATH (it allows folks to install all kinds of things without overloading the PATH environment variables).
You can create an empty file ending in .ignore (e.g x86\adplus.exe.ignore) file next to the one you don't want to be shimmed. This is documented on the wiki. You can even do it programmatically during install based on something like OS architecture.
It sounds like you have a need for one of them sometimes and the other at other times on the SAME machine. I would suggest .ignore files for both files, and likely using Get-BinRoot to push the files to a tools folder (you get to define where the location of this is). Then you can set the process PATH temporarily for whichever one you need and it doesn't persist to the actual path. You can even set one on the path and then override it when you want the other.
Since the automation scripts are just PowerShell, you have all kinds of options here.
I've had many questions about Python for which a suggested answer is often "use virtualenv", but I have a (lovingly maintained and perfectly functioning) Python installation that I'm loath to disturb.
I want to be absolutely sure, so I'll ask twice: Does use of virtualenv in any way disturb my "real" Python installation? Using virtualenv does not in any way modify the files or paths in my "real" installation, right?
Virtualenv creates separated Python environment. Python interpreter is linked from one of system-installed that you choose creating virtualenv( --python commandline switch) and, optionally, wheater use or not system site-packages (--system-site-packages).
All packages that you install using virtualenv remains only on virtualenv directory site-packages folder and do not mess system packages.
I am trying to link against the libconfig++ library using cmake. I installed the library
using apt-get so I am assuming it will have a .cmake file so I can use find_package. Problem is I don't know what package name to use. I tried libconfig, config, config++ as the package name to no avail.
As a general question, how does one find out which package is associated with a library.
I know that find_package looks into CMAKE_MODULE_PATH to see if there is a .cmake script. How to I find out what is the value of CMAKE_MODULE_PATH on my system. It's not an environment variable. I am running ubuntu 12.04.
Any help is appreciated.
To use find_package you need to have corresponding Find or Config cmake file. But library may not to provide it, seems with your library is such a case. You can use find_library for finding libraries and find_path to find include directories. With these commands you can even write FindXXX.cmake yourself.
CMAKE_MODULE_PATH is not an environment variable, it is CMake's one. This variable is intended for you to set, if you have additional directories with modules, by default it's empty. This is used in the "Module" mode. In this mode CMake searches FindXXX.cmake in the CMAKE_MODULE_PATH (your modules) or in modules shipped with CMake and if it's found, it then used to find library and it's headers.
If that module wasn't found, it then switches into "Config" mode. On Unix it searches for ConfigXXX.cmake in the following directories:
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/
This files is shipped with the library, so there is no need to find anything, they contain all information, where library and includes located, etc.
About naming scheme, there is no standard one. You can look at Standard CMake modules. Modules found in internet for your library named FindLibConfig.cmake
For your case, library ships without corresponding cmake file, so you should write it your self (or find already written) and add directory with that file to CMAKE_MODULE_PATH.
I suggest you to read how find_package command works and how to write FindXXX.cmake files.