I want to change some options passed to the CMake command through the plugin code. Unfortunately I can't figure out how to do it.
Is there any API to communicate with CLion specific functionality?
You said "CMake command", which is unclear. I guess you want to change the CMake location.
This code can give you a CPPToolchains.Toolchain instance:
val Project.toolchains: CPPToolchains
get() = ServiceManager
.getService(this, CPPToolchains::class.java)
.toolchains
.firstOrNull()
Or if you don't understand Kotlin, use Java:
CPPToolchains.Toolchain tools = ServiceManager
.getService(project, CPPToolchains.class)
.getToolchains().get(0);
And you can get the settings by codes like
tools.getCMake().getExecutable()
Or change them by invoking methods like
com.jetbrains.cidr.cpp.toolchains.CPPToolchains.Toolchain#setCustomMakePath
Just explore through those classes and methods, you'll get what you want.
If you still can't find any, try replace CPPToolchains in the first two codes with CMakeSettings and see if there's something in the class that fits your expectation.
Settings->Build, Execution, Deployment -> CMake -> CMake Options
Related
I am hacking around a problem we've created for ourselves. What I would like to do is log a warning in our TFS builds for any code that is instantiating a specific class. I don't want a run time warning (I've got one in place already), I want a build time warning that ProjectX is using BadClass.cs. The idea being it will give us an additional place to see things that need to be fixed once our hack is no longer needed.
So something like this:
public class BadClass
{}
public class OkClass
{}
public class MyBadService
{
var a = new BadClass(); <-- Logs a warning to the build output
}
public class MyOkService
{
var a = new OkClass(); <-- Does not log a warning
}
Edit:
I do not like the idea of using Obsolete; its a misnomer. We've already got code with Obsolete attributes and this would get lost in the noise. I don't want a generic warning that I can't control the message for. I want bright neon signs with klaxons firing and a thousand exclamation points in the message. Basically everything I can do short of failing the build. I'm using the #warning precompiler directive right now and its mostly doing what I want but it requires a human to remember to add the warning. I'm looking for something more automagic. I've seen third party libraries do stuff like this so I know its possible.
Why not just use the Obsolete attribute? It can generate a build warning for you:
https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute?view=netframework-4.8
You can even make it emit an error too if you want.
The answer could be negative I think.
It seems that you use or call msbuild.exe to build your C# projects. But as far as I know, MSBuild in fact calls csc.exe to build C# projects in build time.
So actually what you want is logging a warning when the compiler compile the C# code if it recognize somewhere in your code uses the BadClass in build time.
If you have the source code of BadClass in the same solution, add a project reference format to the xx.csproj which contains BadClass, and set a #warning in the BadClass it may generate the warning in build time.
But I think the scenario you're in is something like: You developed one Assembly and distribute it to your user, so you want it generates a warning when the user calls one BadClass in your assembly and builds his own project to remind him of taking care when using this bad class. If so, this is impossible for msbuild AFAIK. If I misunderstand anything, feel free to know me know :)
Update:
As Daniel and Johnson said, ObsoleteAttribute is enough to do this. Though no valid way to generate warnings from msbuild aspect directly, but msbuild will call C# compiler during build process, so generates a compiler warning can output to build output window.
ALL,
I'm trying to find a memory leaks in my software written in C++. Everything is written and compiles fine when I try to run the build.
However, when I try to do "Product->Profile", the compilation fails. The compiler couldn't find some header file.
What is wrong and how do I fix it?
TIA!
Check the Scheme. Product -> Scheme -> Edit Scheme or Command <. See what's different within them.
Another place to look is Project Settings: General -> Linked Frameworks or something under Build Phases.
I want to force Xcode to use a custom compiler ('clang-llvm' build from the src) so I can use the clang plugin. My Xcode version is 7.3.1.
People say it is possible with custom toolchains. I didn't make a research on them because easier solution worked well for me:
It is also possible to run frontend plugins directly by setting appropriate "build settings" of Xcode. (Several ways to do this, you can set them on the command line for instance: xcodebuild build FOO=bla.) Here are a few build settings that I found useful to inject C flags:
OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS or to replace the compiler(s) and linker(s):
CC, CPLUSPLUS, LD, LDPLUSPLUS, LIBTOOL
The same approach works to control the "analyze" action: CLANG_ANALYZER_EXEC, CLANG_ANALYZER_OTHER_FLAGS
Disclaimer: some of those build settings are undocumented (afaik). Use at your own risk.
(Taken from [cfe-dev] Compile/refactor iOS Xcode projects)
For me it was enough to define the following User-Defined Settings in Build Settings of Xcode projects:
CC=my-c-compiler
CXX=my-cxx-compiler
LIBTOOL=my-linker-for-static-libraries
If you use CMake, the way to inject your compiler automatically is to use
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CC "${YOUR_CC}")
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CXX "${YOUR_CXX}")
Couple of years ago I've written an article that addresses exactly the problem you describe: Creating and using Clang plugin with Xcode
To enable custom clang you need to actually patch internals of Xcode.app itself, it is technically doable but:
it will break when you update Xcode
it will work correctly on your machine
the version of a plugin and your compiler should match, i.e.
they should be compiled using the same tree
So in general it doesn't really scale, so be careful :)
There's a somewhat obscure feature of Xcode where it supports "alternative toolchains". For example, Swift.org provides installable toolchains for Swift built from current sources.
Unfortunately, while Apple's documentation describes how to install and use such alternative toolchains, it doesn't describe how to create them. There are scripts in the Swift source base which build a toolchain and you can look at them to figure out how it's done. They are in https://github.com/apple/swift/tree/master/utils. Start at build-toolchain, which calls build-script and go from there.
Method 1: Change the User Defined settings
Under the project or target Build Settings add the User Defined settings for
CC=/path/to/cc
CXX=/path/to/c++
This is useful if you have a single compiler or linker you want to call, or if you want to call out to a trampoline that decides what to call on the fly.
Method 2: Create a complete custom toolchain via plugin
Using Clang LLVM 1.0.xcplugin as a template (found in the Xcode.app plugins folder), you can modify the plist to point at your own alternative compiler and linker.
This OLLVM on iOS tutorial walks through it.
From project setting go to build setting with target selected. then select All beside the Basic from the top bar. then under build option you can see the compiler option.
Refer below screenshot,
Update :
I think you should refer Using C and C++ in an iOS App with Objective-C++ and this tutorial.
There seem to a variety of questions like this one without any clear solution that is true for Xcode 7 (or even other versions of Xcode).
I have a version of GCC that I'd like Xcode to use when it compiles. It is not the standard GCC but customized for a different platform. I can specify and use this compiler fine in Eclipse, but would rather use Xcode. The Build Options only list LLVM and nothing else. When I try to add via "other" in that section, all I get is this empty popup:
What goes in this box? I would think that it should be no big deal for Xcode to simply use a GCC that I have available at a specific path on my system, but this appears to be quite complex.
Update: Apparently there is a supported mechanism for installing externally-provided tool chains in Xcode that I wasn't aware of. For example, one can download packages from swift.org that install alternative tool chain packages into /Library/Developer/Toolchains or ~/Library/Developer/Toolchains. Once one of those is installed, Xcode has a GUI option to switch the active tool chain.
There was a recent change to the Swift sources to include a script for building one's own custom tool chain from them.
If you view the Quick Help for that build setting (View > Utilities > Show Quick Help Inspector) or configure the build settings view to show setting names instead of titles (Editor > Show Setting Names), you'll see that that setting is GCC_VERSION.
If you look that up in the Build Settings Reference, you find:
GCC_VERSION
Description:
Numeric identifier. Identifies the GCC version to be used to compile
the target’s source files. When the target’s “System C rule” is set to
GCC System Version (instead of a specific version number), this build
setting is not available in Run Script build phases.
Values:
2.95.2
3.1
3.3
4.0
Default value:
GCC system version.
Specified in:
Project Info > Rules > “System C rule.”
Target Info > Rules > “System C rule.”
Affects:
GCC_VERSION_IDENTIFIER.
That's actually a bit out of date. It says it's specified by fiddling with a build rule (not setting) called the "System C rule". You used to change the version there but now there's a direct build setting for it.
Anyway, this probably doesn't help you do what you want to do. I doubt there's any value you could put in there that would do something useful, let alone use a third-party compiler.
However, the explanation does have a hint. It mentions the System C build rule. You could modify the build rules on the Build Rules tab of the target configuration screen. You can find the System C rule and press the button to copy it to your target, which will let you specify a custom script to process C files (including Objective-C and C++).
Implementing such a script is non-trivial. The inputs, expected outputs, and required behavior of the script are not well documented. There are various environment variables available for the use of such a script. Some are the build settings. You'll need to translate the relevant settings into compiler options. For example, translate the CLANG_WARN_BOOL_CONVERSION setting into the corresponding -Wbool-conversion option.
Some of the other environment variables indicate which file you should operate on, such as INPUT_FILE_PATH, INPUT_FILE_NAME, etc.
You need to tell Xcode what file(s) your rule outputs. These can be based on the input environment variables/settings, such as $(OBJECT_FILE_DIR)-$(CURRENT_VARIANT)/$(CURRENT_ARCH)/$(INPUT_FILE_BASE).o.
In general, this is just not something that Xcode makes easy.
Someone wrote a plugin that will allow you to use gcc from Xcode.
http://hamelot.io/programming/add-gcc-compiler-to-xcode-6/
If you have a custom gcc then you would need to change the paths around etc but the plugin should work.
I'm trying to use differents configurations for multi-library use.
I explain : i have to use many library for one solution, but i need to change the configuration for each library target, for a debug use of my solution some library will be in 'debug' mode but some other needs a 'Render' configuration. (It's 3rdParty project i can't edit them)
I want to know if its possible.
Thanks !
Here an example the result i wanted to have :
http://i48.tinypic.com/mtugqf.png
You can almost do this. CMake allows for extra configurations by setting CMAKE_CONFIGURATION_TYPES, so in your case this would be
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES};Render" CACHE STRING "" FORCE)
This needs to be after the project command.
However, this adds a new configuration type to all targets. I don't think CMake has the ability to mix different configurations for individual targets. You'd still have to manually modify the specific libraries' configs via the Configuration Manager once CMake had created the .sln.