we working on a C++/CMake project, that needs to run in both Windows and Linux. On Windows, we have to work with a number Visual Studio versions, both in 32- and 64 bit. In order to alleviate dependency issues in our team, we have manually compiled a number of dependencies for each configuration(vs2013_x64, vs2013_x86, vs2012_x64, vs2013_x86...) and installed them (using make install or similar commands) to a common folder for each configuration. Now we have a folder called "vs2013_x64" for example, that contains similar folders as /usr would on linux: CMake, include, lib, share, ...
Now my question is: How do I have to set up CMake, so that it treats this vs2013_x64 folder just like it does /usr on Linux?
I found a number of variables that seem related, for example
CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT. However, setting them to my vs2013_x64 folder for example does not work: FindXXX.cmake files in the vs2013_x64/CMake folder are not found, and even when I manually set the CMAKE_MODULE_PATH to that CMake folder, the Find* scripts are unable to find the include they are looking for, because the vs2013_x64/include folder does not appear to be searched.
A solution that did work was to set the CMAKE_PREFIX_PATH. This is nice and almost what I need, but lets say that on Linux, I would not want it to look at /usr at all under any circumstances. This would not be possible using the PREFIX_PATH solution if I understand it correctly.
From what I understood from the documentation,
CMAKE_FIND_ROOT_PATH is more configurable and has a number of additional variables such as CMAKE_FIND_ROOT_PATH_MODE_PROGRAM, CMAKE_FIND_ROOT_PATH_MODE_LIBRARY and CMAKE_FIND_ROOT_PATH_MODE_INCLUDE. This makes me believe that FIND_ROOT_PATH is what I actually SHOULD be doing - yet I am unable to make it work
Does what I am trying to do make sense? Can anyone clarify when and how to use what? Ideally, I would like a solution that allows me to set the search path to my vs2013_x64 folder on Windows, that defaults to /usr on Linux, but can optionally also be set to another directory containing lib/include/cmake folders. In addition, it would be nice if searching ONLY occurred in the configured path and nowhere else (to avoid mistakenly picking a library that was installed system-wide).
Thanks!
Related
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
According to Apple's Developer Docs the Library global allows one to import compiled scripts so they can be used as a library in one's current script. This works just fine if you were to do something like the below code with myLibName.scpt located at ~/Library/Script Libraries:
myLib = Library('myLibName');
myLib.myLibMethod() // Works just fine
But, the docs also claim that one can export an environment variable — OSA_LIBRARY_PATH containing a string of : delimited paths — and Library() would then defer to that list of paths before proceeding to it's default path: ~/Library/Script Libraries. Ya know, like the bash environment variable Path. Here's the relevant piece of documentation below; it describes the path hierarchy:
The basic requirement for a script to be a script
library is its location: it must be a script document in a “Script
Libraries” folder in one of the following folders. When searching for
a library, the locations are searched in the order listed, and the
first matching script is used:
If the script that references the library is a bundle, the script’s
bundle Resources directory. This means that scripts may be packaged
and distributed with the libraries they use.
If the application running the script is a bundle, the application’s bundle Resources
directory. This means that script applications (“applets” and
“droplets”) may be packaged and distributed with the libraries they
use. It also enables applications that run scripts to provide
libraries for use by those scripts.
Any folders specified in the environment variable OSA_LIBRARY_PATH. This allows using a library
without installing it in one of the usual locations. The value of this
variable is a colon-separated list of paths, such as /opt/local/Script
Libraries:/usr/local/Script Libraries. Unlike the other library
locations, paths specified in OSA_LIBRARY_PATH are used exactly as-is,
without appending “Script Libraries”. Supported in OS X v10.11 and
later.
The Library folder in the user’s home directory, ~/Library.
This is the location to install libraries for use by a single user,
and is the recommended location during library development.
The
computer Library folder, /Library. Libraries located here are
available to all users of the computer.
The network Library folder,
/Network/Library. Libraries located here are available to multiple
computers on a network.
The system Library folder, /System/Library.
These are libraries provided by OS X.
Any installed application
bundle, in the application’s bundle Library directory. This allows
distributing libraries that are associated with an application, or
creating applications that exist solely to distribute libraries.
Supported in OS X v10.11 and later.
The problem is that it doesn't work. I've tried exporting the OSA_LIBRARY_PATH variable — globally via my .zshrc file — and then running a sample script just like the one above via both the Script Editor and the osascript executable. Nothing works; I get a "file not found" error. I found this thread-where-the-participants-give-up-hope online; it doesn't explain much. Any thoughts?
On a somewhat related note, the Scripting Additions suite provides two other methods — loadScript and storeScript — that seem like they might be useful here. Unfortunately, when you try to use them, osascript gives you the finger. Though, I did manage to return what looked like a hexadecimal buffer from a compiled script using loadScript. Anyway, any insight you guys can shed on this would be much appreciated. Thanks.
The OSA_LIBRARY_PATH environment variable is ignored by restricted executables when running with System Integrity Protection enabled.
To workaround this limitation you can either turn off SIP, or you can use an unrestricted executable.
For instance, to make osascript unrestricted, you should first make a copy, and then re-sign it with an ad-hoc signature:
cp /usr/bin/osascript ./osascript
codesign -f -s - ./osascript
Once you have the unrestricted osascript, you can run it with the OSA_LIBRARY_PATH environment variable set like this:
OSA_LIBRARY_PATH="/path/to/libs" ./osascript path/to/script.scpt
As a lousy alternative, you can put a symlink at one of the "Script Libraries" folders that osascript would look at and point it to the folder you want. Note that the symlink must be a replacement for the entire folder, it can't just exist inside of it.
rm -rf ~/Library/Script\ Libraries
ln -s "/Your/Custom/Path/Goes/Here/" ~/Library/Script\ Libraries
Tested on 10.13.2
I have multiple websites which use /wwwroot/assets folder (html theme, css and javascript files) to load the static content.
Currently I am copying assets folder in each site. All of my projects are sitting under a common parent directory.
I don't want to copy the /wwwroot/assets folder into each website. Is there a way to share one assets folder between all sites. May be by providing a direct file system path or something?
At the moment it's not clear from the documentation what sorts of values the webroot key in the project.json file will accept, but so far it would appear that Visual Studio doesn't care for very complicated paths. For example, setting the value to ../wwwroot causes the entry to disappear in the Solution Explorer.
If you look at the kpm code that bundles your project up for deployment, it appears to combine your project's directory with whatever is stored in the wwwroot key, so even though Visual Studio may not understand it, relative paths appear to be supported. Using kpm bundle from the command line confirms this, and a directory above src bundles correctly when using a relative path.
Depending on your particular needs, there is one way that should work that makes kpm and Visual Studio happy, but it will depend on your build environment as to whether that is a good option for you.
Windows, OSX, and Linux all support creating symbolic links for directories, which would allow you to have your assets directory in one location in the filesystem and then create links to it elsewhere. For example, if you had assets in /projects/shared/assets, you could create a link in both of your other projects (e.g. /projects/project1/src/wwwroot/assets) that point to the "real" location.
In Windows, the command would might something like this
mklink /j "C:\link\to\create" "C:\path\to\assets"
So if you did
mklink /j "C:\source\shared\assets" "C:\source\project1\src\wwwroot\assets"
project1 would appear to have an assets directory inside of wwwroot and the build process would be happy since it would appear to each project that the files were local. One thing to note here is that Windows supports a number of different sorts of links. /j specifically creates a junction rather than a true symbolic link. The differences are a bit subtle, but this is a good description of the differences. It is enough to know that if you're working locally, the /j command doesn't require administrative rights and Visual Studio and kpm will both be happy.
In OSX and Linux, the command is similar:
ln -s /link/to/create /path/to/assets
and like Windows, they support different sorts of links.
In any case, under the right circumstances, this might work well without needing any special support from the new ASP.NET project structure, but it would be nice to eventually have that as well.
I am developing a library which uses CMake to control it. It would be good to provide a "FindXXX.cmake" which locates the library and header files. This file would enable the users to use the command "find_package(XXX)" to find my library.
However, I don't know how to install my lib's "FindXXX.cmake" to an correct location. I failed to find a CMake's build-in mechanism to install a "FindXXX.cmake". In addition, CMake's variable "CMAKE_MODULE_PATH" is a list of directories, so I cannot install according to that vairable because I cannot decide which specific directory to use.
If the copy of CMake is installed to a standard location(i.e. use no prefix etc) then this can be done by placing the file in /usr/share/cmake/Modules/ directory.
If you are going to supply a bundle probably you can add some commands to check if the cmake is available. if yes you can check for cmake --system-information|grep _INCLUDED_SYSTEM_INFO_FILE value from that to get modules directory.
Otherwise there's no way you can do that.
A workaround can be done i.e. if there is a binary in your bundle then you can add a command line option for placing this file.
I have written a CMake module that contains a couple of useful macros that I would like to use across a number of other CMake projects. However, I'm not sure where to put the module.
I would like to be able to do this inside each project that uses the macro:
include(MyModule)
However, I'm not sure if there is an easy and cross-platform way of achieving this. In fact, I can't even get it to work on Unix. I put the module (MyModule.cmake) in the following locations:
/usr/lib/cmake/
/usr/lib/cmake/Modules
/usr/local/lib/cmake
/usr/local/lib/cmake/Modules
...and the project with the include() was unable to load the module.
What is the correct location for this module? Is there a better approach?
I should also point out that the macros are not related to "finding" a third-party library and therefore have nothing to do with find_package().
Put the module in a directory of your choice, and then add that directory to CMAKE_MODULE_PATH using list(APPEND).
You can even host that module somewhere and then download it via file(DOWNLOAD). If you download it to the same directory as the current CMake script being processed, you just include(MyModule.cmake) and don't need to modify CMAKE_MODULE_PATH.
You could download the file to a common location on disk and then add a check using if(EXISTS "${module_location_on_disk}") to skip the download if it's already downloaded. Of course, more logic will be required if your module changes, or you want to have a common location and multiple versions of the module, but that's out of those scope of your question.