I would like to perform the equivalent of
mkdir build && cd build
cmake ..
sudo cmake --build . --target install
from within Clion. The tricky part is to add the "sudo" for the install target. In theory there is an option for this, as described here: https://www.jetbrains.com/help/clion/running-cmake-targets-before-launch.html#0
quote:
"Set the Run with root privileges checkbox to run the target with administrative privileges"
That sounds good, however (on ubuntu, clion installed from the snap store build 2021.2.2
Build #CL-212.5284.51, built on September 16, 2021) this box only appears when the whole application is launched with super user privilege (sudo clion) in which case I have other issues that prevent me from building. Also I find this pretty invasive, having to give privilege to the whole application, when it is only needed for one specific subtask.
How can I tell clion to build a target with super user privilege, without launching clion as root?
Related
When reading through this:
https://www.llvm.org/docs/CMake.html
It tells you how to install to a target, but it doesn't tell you how to install to the system.
cmake --build . --target install
I am not sure what the target is in this case, nor how to properly configure it so it appears as a standard installation into my ubuntu system, insofar as it would be functionally the same as if I installed the development debian packages, and have it picked up by any other build looking to see if the libraries are installed.
Hence, how do I install all the projects under the llvm suite, from source, into Linux?
That command will install LLVM and all the configured projects (via LLVM_ENABLE_PROJECTS) to whatever location you specified in the first step with the CMAKE_INSTALL_PREFIX variable.
If you did not set it, it takes on a platform-dependent value, most likely /usr/local on Linux. This is an appropriate place to put it. I would discourage you from trespassing on the package manager's territory. Untold misery is likely to result.
A "target" in CMake (and many other build systems) is just "something that must be done". Usually it's "compile something to a file with a corresponding name", but it can also be "run an installation script". CMake creates an install target for that purpose in every project. It's also a popular convention in Make/autotools based build systems.
I'm trying to create a CPack-based MacOS installer for an audio plugin project. The default location of MacOS audio plugin is in the /Library/Audio/PlugIns/ folder which needs root rights to be written to.
AFAIK CPack takes the destination path for the installed artifacts from the path specified in the CMake INSTALL command, so my CMakeLists.txt looks like that:
# CPack takes these paths as the locations where the plugins should be installed in the end
install (TARGETS MYPLUGIN_VST3 LIBRARY DESTINATION /Library/Audio/Plug-Ins/VST3 COMPONENT VST3)
install (TARGETS MYPLUGIN_AU LIBRARY DESTINATION /Library/Audio/Plug-Ins/Components COMPONENT AU)
# This makes sure that only the two components and nothing else is part of our installer
SET (CPACK_COMPONENTS_ALL VST3 AU)
# We want to use the native Apple GUI installer
SET (CPACK_GENERATOR productbuild)
Now, when I call cpack to build the installer it fails because of a permission issue as it installs the plugins as a first step before building the installer. The only solution I found was running cpack with root rights to let it write to these locations during the install step which seems like bad practice to me and might be even worse when trying to run this on a build server in future. As I don't need the install step but only want the resulting installer, I wonder if there is any way to avoid the install step and let CPack grab the files to wrap into the installer directly from the binary directory where they were placed after build. Didn't find anything regarding that in the documentations, but I'm just starting with CMake and CPack, so I might overlook something obvious here
I need to setup a simple and compelling dev environment for small proyects written in Haskell in Windows machines for freshmen.
I have tried several ways to integrate Haskell into VSCode in Windows with no success.
I had a nice setup a few years ago, but I´m finding problems with dependencies recreating that environment:
Editor: Atom
Global binaries build using: stack with ghc-mod hlint stylish-haskell
Atom plugins: language-haskell, ide-haskell, ide-haskell-repl, haskell-ghc-mod
It seems that the "cool" way right now is Language Server Protocol + VScode. ghc-mod seems not to be mantained anymore, Intero has reached EOL, HEI is merging with another project... Having a stable and updated dev environment looks like a moving target.
So, the question is: does anyone have reproducible step-by-step instructions for having VSCode working with Haskell in Windows?
I will test any suggestion in a fresh Windows 10 64bits VM and report the results.
Note: VSCode + Docker container is not an option. Most of the student´s machines have 4GB RAM.
Thanks in advance.
There's a tool called ghcid (not to be confused with ghcide) that, while nowhere near a full-blown IDE, is pretty robust and provides some niceties like re-compiling on save and showing compile errors. It doesn't support go-to-definition though. It has a VSCode plugin.
Here's a possible way of setting up things in Windows:
Download the GHC 8.8.3 binaries for Windows from here.
Download the cabal-install 3.0.0.0 binaries for Windows from here.
Decompress them in some folder.
Add entries to your PATH environment variable so that it has access to the /bin folder of the GHC installation and to the folder containing the cabal executable.
Open a Powershell console.
Run cabal udpate
Run cabal install --install-method=copy --installdir=somefolder ghcid to install the ghcid executable, where "somefolder" is the destination folder. (If the installation fails, try running the command from a Git Bash or Cygwin terminal as a workaround.) Put the destination folder in PATH.
Open (or restart) VSCode and install the "Haskell Syntax Highlighting" and haskell-ghcid plugins.
Go to an example cabal project, use the Ctrl-Shift-P shortcut, and execute the Start ghcid action. The ghcid terminal will appear.
Example of a ghcid session showing an error:
The haskell-ghcid plugin can read a .ghcid file in the project root containing flags that should be passed to the ghcid command.
Extra instructions to set up code formatting:
Install the ormulu formatter by running cabal install ormolu --install-method=copy --installdir=somefolder. Again, make sure that the destination folder in in PATH.
Open (or restart) VSCode and install the ormulu plugin.
Now the "Format Document" and "Format Selection" actions in VSCode will use ormulu.
Another way of installing GHC and getting to ghcid and ormulu could be by using the stack tool, which handles GHC installation by itself.
I'm evaluating CLion 1.2.1 on an existing project which is already using CMake. The project is made up of a few library modules and a single executable.
I have an install target which I use to collect the executable and a configuration file together in a bin folder for debugging:
...
install(TARGETS ${PROJECT_NAME} DESTINATION ${CMAKE_BINARY_DIR}/bin/)
install(FILES config.xml DESTINATION ${CMAKE_BINARY_DIR}/bin/)
When building on the command line I'd just run:
make install
which as expected builds the binaries and if successful then runs the above install commands.
My problem is that I can't get CLion to run the 'install' target. I expected to be able to create a new Run/Debug configuration but the Target: dropdown only contains those targets added using add_executable() and add_library().
I also tried adding 'install' to the Build options in the Settings dialog. That however runs install for every target now including 'clean' which is not right.
UPDATE: As of 2018.1 EAP, build 181.3741.16, CLion supports running cmake install if your project defines install targets:
(source: cloudfront.net)
Original Answer:
I don't think that CLion implements this feature yet. However, you can work around this limitation by adding a CMake "custom target" (using add_custom_target()) that will execute the make install command:
add_custom_target(install_${PROJECT_NAME}
$(MAKE) install
DEPENDS ${PROJECT_NAME}
COMMENT "Installing ${PROJECT_NAME}")
Now, all you have to do is "build" the install_YOUR_PROJECT_NAME target from the "targets" menu in CLion.
Update:
A more cross-platform technique might be the following:
add_custom_target(install_${PROJECT_NAME}
"${CMAKE_COMMAND}" --build "${CMAKE_BINARY_DIR}" --target install
DEPENDS ${PROJECT_NAME}
COMMENT "Installing ${PROJECT_NAME}")
#maddouri 's comment already addresses your question. Alternatively, Under Settings -> Build, Execution, Deployment -> CMake, you can also set Build Option for Debug or Release build type to something like -j 2 install. With this setting, whenever CLion builds the code, it will install your targets, too!
I have an XCode project with two executable targets, which I use for my own work (that is, I don't sell or publish the applications, but they are still important to me), which depends on one external project. Until now, it has been unproblematic to build the Application(s) and install into the /Applications folder. What I did, was go into the command line and type:
sudo xcodebuild -scheme Trainer install
This would install the target Trainer into the Applications folder, and the application could be run from there. If I tried to specify the target using -target Trainer instead, it would not work, as it would not find dependencies in the external project. Anyway, since last time it worked, two things have happened:
I have upgraded to OS X 10.11
I have upgraded XCode to Version 7.1.1 (7B1005)
Whatever the reason, xcodebuild does no longer install the built product into the /Applications folder. The last lines from the build log, when building with xcodebuild now are:
Touch /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/BuildProductsPath/Release/Trainer.app.dSYM
cd /Users/pbholmen/Projects/SoundSample
/usr/bin/touch -c /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/BuildProductsPath/Release/Trainer.app.dSYM
RegisterWithLaunchServices /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/InstallationBuildProductsLocation/Applications/Trainer.app
cd /Users/pbholmen/Projects/SoundSample
builtin-lsRegisterURL /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/InstallationBuildProductsLocation/Applications/Trainer.app
** INSTALL SUCCEEDED **
I have tried to simply copy the Trainer.app that it builds into the /Applications folder, but if I double-click on it, it just won't run. Of course, the Application works when built and run from within XCode, both with the "Debug" and "Release" configuration.
Back when it did work, this would be the last lines of the build log (in Terminal):
Touch build/Release/Trainer.app.dSYM
cd /Users/pbholmen/Projects/SoundSample
/usr/bin/touch -c /Users/pbholmen/Projects/SoundSample/build/Release/SoundSample.app.dSYM
RegisterWithLaunchServices /Applications/Trainer.app
cd /Users/pbholmen/Projects/SoundSample
builtin-lsRegisterURL /Applications/Trainer.app
** INSTALL SUCCEEDED **
If I try to go into the build log from within XCode, find where it puts the builds, and maneuver into that location in Finder and start the application from outside of XCode, that doesn't work either.
Here you can see my Deployment build settings for the target:
Build settings
Under "Deployment location" I have tried both "YES" and "NO", and under "OS X Deployment target" I have tried both "OS X 10.10" and "OS X 10.11". And all four combinations of the two.
After hours of twiddling, I finally figured out the answer. First off, the command
sudo xcodebuild -scheme Trainer install
is wrong. It was a workaround, because I couldn't get XCode to manage my external dependencies from the command line, even though they were managed correctly within XCode. The correct invocation, for a target other than the project's main target is
sudo xcodebuild -target Trainer install
Previously, the first invocation would work, the product would be installed even though the scheme doesn't really include an "Install" action. This is clearly no longer so with XCode 7.1. The reason I couldn't use -target instead of -scheme previously, was because my target was dependent on a framework in another project, which was added to my main project (the external project was added, not just the framework). All dependencies were set up correctly in my main project, and from the command line it worked only when specifying the scheme, not when specifying the target. When running xcodebuild with -target specified, xcodebuild would not find the modules in the external project (a Swift framework).
I have now figured out the reason for this. The project which contained the external framework was not set up correctly. It was set up to install the framework into a bogus location (/tmp/ProjectName.dst/Library/Frameworks, which is the default). In addition, my main project needed to add /Library/Frameworks into the framework search paths. It seems that when the project is built inside XCode, or for archiving etc... libraries and executables are built into a "private" folder structure separate from the system itself. When running xcodebuild install, however, it tries to install the external frameworks into the proper system folders, and link it there. Therefore, setups that work inside XCode may not work when running 'xcodebuild'.
EDIT: It works now, but StackOverflow won't let me mark it as correct before two days.