In my project I had to copy a library into my source to make some minor adjustments.
This library throws a couple of warnings when compiling. I don't like that ;-)
Since I don't want to change the library code any more than absolutely necessary, I do not want to put #Suppress lines into the library code.
Is there a possability to advise the compiler "Please ignore warnings, but only in src/foo/bar"? Maybe a compiler flag?
I am using a Gradle build, if that opens additional options.
foo.bar is a package and packages can not be suppressed.
Your options are:
Remove compiler warnings entirely
Create separate source set and compile task for the problematic code.
Fix the warnings.
Related
I am stuck with a problem for which I searched on various threads unsuccessfully.
I have a project built with autotools utilities. This project relies on preprocessor directives which activate blocks of code depending on the presence of libraries or other stuff.
The problem I am facing is that once the project is built, for example like:
./configure --enable-mpi=yes && make
(Note that --enable-mpi=yes is set to add -DMPI_LIB=1 to the list of compiler flags.)
If I rebuild the project like
./configure --enable-mpi=no && make
Nothing is done for make. I think it is normal behaviour as no files changed except compilation flags (-DMPI_LIB=0 in that case).
How then can I add a dependence on flag changes in Makefile.am ?
I came across this thread: Makefile trigger rebuild for C/C++ preprocessor directives. Unfortunately I do not know how to adapt this to Makefile.am as there seem to be pretty high limitations in conditionals handling in Makefile.am.
Thank you for any advice !
EDIT
I may have found a workaround, or maybe the right way of doing it in another thread how to force recompile when changing Makefile flags? (I am not much experienced with make). If I add Makefile as a dependency to my object files it does the job, e.g. recompiles whenever a compilation flag changed.
I am new to CMake and my IDE (CLion) has not yet supported the intellisense for add_custom_target() include source files. One of the comments in the YouTrack Issue, mentioned that a add_library(_fake) would do the trick. I tried several combinations of getting my custom target sources linked to _fake library, but it won't work for me.
I need to use clang for this target and CMake does not seem to provide a way to pick the compiler for individual targets, so I am stuck with custom_target approach. When I add the custom target sources to _fake library, it can't compile with cc.
While VSCode seem to provide intellisense for custom target, CLion fails to do so. Is there a way to not compile the _fake library to avoid compilation errors from cc and yet get the intellisense working? If not how can I get CLion intellisense working just like VSCode can do without any trick?
In my project some code can be optional compiled in a different language (nasm & fortran), but it's also fine to compile the project without having these compiler installed. E.g. on Windows.
I would like to check if the the compiler are installed, before enabling the languages with enable_language
enable_language(ASM_NASM)
enable_language(Fortran)
If I use enable_language without an additional check, CMake stops with an error message.
(At the moment I check for if (MSVC) as workaround.)
Btw. I have a similar problem with the check for Qt. The check don't stop with an error, but generate a lot of noisy warnings.
So use check_language to check if a language can be enabled.
When specify linkerOpts, we need set absolute path for -L option, but it's easy to break.
In older version, setting linkerOpts in build.gradle could work, but in 1.3.50, it warns that "-linker-option(s)/-linkerOpts/-lopt option is not supported by cinterop. Please add linker options to .def file or binary compilation instead.", and build do fail with "Undefined symbols" error.
What could I do?
This option is going to be deprecated once, so the warning was intentionally added after the 1.3.50 release. The motivation here is that one should prefer to set all linker options, even platform-specific, via .def file.
But, the build should not break apart in this case. Can you add the script contents, to make it clearer - what exactly led to the error?
UPD: After the GH project was shared in the comments I want to add some details here. This problem is described in the documentation here, this part:
Often it's necessary to specify target-specific linker options for a binary which uses a native library. It can be done using the linkerOpts property of the binary.
So, in this particular case, it will be correct to add the option to the binaries section instead of the cinterops. In the end, I made things together with
binaries {
all {
linkerOpts = ['-L'+rootProject.projectDir+'/libs/NativeBase64/iOS/', '-lNativeBase64']
}
}
CMake's message() directive has an AUTHOR_WARNING mode, however the documentation (v3.11.1) doesn't say anything on what the differences are between an AUTHOR_WARNING and a regular WARNING.
The documentation states these modes and their description as follows:
WARNING = CMake Warning, continue processing
AUTHOR_WARNING = CMake Warning (dev), continue processing
Author warning are meant to warn the author (developer) of a CMakeLists.txt, but not a user of it. With the CMake arguments -Wdev, -Wno-dev, and -Werror=dev you have control over how to these warnings are handled (documentation).
The idea is that users should not be scared or annoyed by warnings they cannot change anyway, because they are not supposed to modify this part (of potentially third-party) code. This includes programmers who include CMake code from others and don't want to warned about issues they cannot fix within their code.
Since CMake 3.5, the dev flags also suppress or enable deprecation warnings, following the spirit of warning only people who can fix the underlying issues.