I am using the modernize-use-using checker from clang-tidy through the run-clang-tidy-3.9.py script over a whole CMake project (I use the compile_commands.json file generated by cmake).
This works great for other modernize checkers (auto, for loops, override, etc.), but the modernize-use-using checker finds "conflicts" like for instance:
There are conflicting changes to /home/OTB/git/otb/Modules/Filtering/ImageManipulation/include/otbVectorRescaleIntensityImageFilter.h:
The following changes conflict:
Replace 48:3-48:84 with "using RealType = typename itk::NumericTraits<typename TInput::ValueType>::RealType"
Replace 48:3-48:84 with "using RealType = typename itk::NumericTraits<typename VariableLengthVector<double>::ValueType>::RealType"
Replace 48:3-48:84 with "using RealType = typename itk::NumericTraits<typename VariableLengthVector<float>::ValueType>::RealType"
Looking at the source code, I don't understand why there would be such conflicts, but the issue is that because of these, no other fix is applied to my project. These are very few conflicts relative to the number of fixes, but I can't find a way to force clang-tidy to apply the rest.
The clang-tidy tool, when run alone has a -fix-errors option, but this is not available for the run-clang-tidy script which uses the CMake commands file.
Any suggestion would be appreciated.
Thanks
Related
I'm facing the following scenario:
Existing project which uses cmake
External 3rdparty library which only comes with Makefiles
The difference of my situation compared to existing questions is that I don't need to have cmake to build the 3rdparty library via the Makefile. Instead, the 3rdparty library provides a library.mk Makefile which has variables like LIB_SRCS and LIB_INCS containing all source and header files required to compile the library.
My idea is to include the library.mk into the project's CMakeLists.txt and then adding those $(LIB_SRCS) and $(LIB_INCS) to target_sources().
My question: How can I include library.mk into the existing CMakeLists.txt to get access to the $(LIB_SRCS) and $(LIB_INCS) for adding them to target_sources()? I'm looking for something like this:
include("/path/to/library.mk") # Somehow include the library's `library.mk` to expose variables to cmake.
add_executable(my_app)
target_sources(
my_app
PRIVATE
main.c
$(LIB_SRCS) # Add 3rd-party library source files
$(LIB_INCS) # Add 3rd-party library header files
)
Using include() does not work as the library.mk is not a CMake list/file.
Since you can't be sure that your target system will even have Make on it, the only option is to parse the strings out of the .mk file, which might be easy if the variables are set directly as a list of filenames, or really hard if they are set with expansions of other variables, conditionals, etc. Do this with FILE(STRINGS) cmake doc.
Your plan will only work if the Makefiles are trivial, and do not set important compiler flags, define preprocessor variables, modify the include directory, etc. And if they really are trivial, skip the parsing, and just do something like aux_source_directory(<dir> <variable>) to collect all the sources from the library directory.
You might also consider building and maintaining a CMakeLists.txt for this third-party library. Do the conversion once, and store it as a branch off of the "vendor" main branch in your version control system. Whenever you update, update the vendor branch from upstream, and merge or rebase your modifications. Or just store it in your existing project, referring to the source directory of the 3rd-party stuff.
I try to build large project with many directories and sub-directories, some of them are being used to create different libs.
using GNU make using same compilation flags. most of the folder are successfully built, but in a specific folder the build failed, and it gets many errors that some definitions is missing.
For instance, the first error is:
In file included from /usr/include/c++/4.8.2/cwchar:44:0,
from /usr/include/c++/4.8.2/bits/postypes.h:40,
from /usr/include/c++/4.8.2/iosfwd:40,
from /usr/include/c++/4.8.2/memory:72,
...
/usr/include/wchar.h:614:9: error: ‘__gnuc_va_list’ has not been
declared
__gnuc_va_list __arg
)
this error comes from simple #include at of the files in this lib, but same sort of error happens for any file and for different standard library headers.
The strength thing is that this project was completely successfully built before i pulled some updates from remote repository. at this merge no changes were done to this file.
Tried to use
g++ -E /usr/include/wchar.h | grep __gnuc_va_list | head -1
result is:
typedef __builtin_va_list __gnuc_va_list;
As i see at this answer, __builtin_va_list shuould be created by gcc, and it probably did create it- otherwise many other files were failed to compile
I can't understand why it happens and why only at this folder/lib.
I had same problem for libhydrogen on windows and mingw 5.3.0, you can just define it to:
typedef void* __gnuc_va_list;
... then it compiled and the delivered tests.c worked.
i think for unix systems its (unsure):
typedef char* __gnuc_va_list;
It seem to me that scons targets are being generated not in declaration sequence. My problem is, I need to generate some code first, I'm using protoc to process a my.proto file into .h and .cc file, I need some pseudo code like this(what should the working code look like?)
import os
env=Environment(ENV=os.environ,LIBPATH='/usr/local/lib')
env.ShellExecute('protoc', '--outdir=. --out-lang=cpp', 'my.proto')//produces my.cc
myObj=Object('my.cc')//should wait until 'my.cc' is generated by protoc
Dependency(myObj, 'my.cc')
mainObj=Object('main.cpp')
My question is:
How to specify this ShellExecution of protoc in SConstruct/SConscript?
How to make sure that the compilation of 'main.cpp' depends on the existence of 'my.cc', in another word, wait until 'my.cc' is generated and then execute?
Your observations and assumptions are correct, SCons will not execute the single build commands in the order that you list them in the SConstruct files. It will run them based on the dependencies of the targets and source files in your build, either defined implicitly (header includes in C++, for example) or explicitly (via the Depends() method).
So you have to define and setup your dependencies correctly, such that SCons delivers the output that you want. For the special protoc case in your example, a special Builder exists that will help you to get the dependency graph right. It is available in our ToolsIndex, where also support for a variety of other languages and dialects can be found.
These special builders will emit the correct target nodes, e.g. when given a *.proto input file, and SCons is then able to automatically detect the dependency between the protoc input file and your main program if you say something like:
env=Environment(tools=['default','protoc'])
env.Protoc([], "test.proto")
env.Program('main', ['main.cpp'] + Glob('*.cc'))
The Glob('*.cc') will detect your *.cc files, coming out of the protoc Tool, and include them as dependencies for your final target main.
You can always write your own Builders and Emitters in SCons, which is the canonical way of making new tools/toolchains known to SCons dependency analysis. In the UserGuide, sect. "18 Writing Your Own Builders", and especially our ToolsForFools Guide you can find more infos about this.
I'm trying to compile the MultiBoost Library with C++11 but I can't make it work. The problem seems to be with the BZip2 Library that is used internally. More specificly there is a wrapper called Bzip2Wrapper to provide a c++ interface to the C library. All the files of the C library are included in the same folder. When using the default make file everything works but when I change
project(multiboost)
to
project(multiboost CXX)
I get the following errors:
libMultiBoostLib.a(Serialization.cpp.o): In function `Bzip2WrapperReader::open(char const*)':
Serialization.cpp:(.text._ZN18Bzip2WrapperReader4openEPKc[_ZN18Bzip2WrapperReader4openEPKc]+0x97): undefined reference to `BZ2_bzReadOpen'
Serialization.cpp:(.text._ZN18Bzip2WrapperReader4openEPKc[_ZN18Bzip2WrapperReader4openEPKc]+0xc5): undefined reference to `BZ2_bzReadClose'
libMultiBoostLib.a(Serialization.cpp.o): In function `Bzip2WrapperReader::close()': ...
The CMakeList file looks like this
# Bzip2
file(GLOB bzip2_SRCS "${BASEPATH}/Bzip2/*.cpp" "${BASEPATH}/Bzip2/*.c" "${BASEPATH}/Bzip2/*.h")
add_library(Bzip2Lib STATIC ${bzip2_SRCS})
#add_library(bzip2 SHARED ${bzip2_lib_SRCS})
...
# adding library to the exec
target_link_libraries(multiboost MultiBoostLib Bzip2Lib)
Any ideas what could go wrong? I don't even know what the problem is.
Thanks!
This does not look like a C++11 error but an error in the Build system.
I have not looked at the Code, but from the output you added something like this
target_link_libraries(MultiBoostLib PUBLIC Bzip2Lib)
should add the missing dependency from libMultiBoostLib on libBzip2Lib.
I found the problem. I was adding "CXX" to my project description which disabled the use of C. Therefore the libraries (in C) could not be compiled. Changing it to "project(name C CXX)" solved this issue. I then also needed to include the line "set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")" to enable C++11 support. Now everything is working.
Thanks a lot!
I'm trying to use clang to profile a project I'm working on. The project includes a rather large static library that is included in Xcode as a dependency.
I would really like clang to not analyze the dependencies' files, as it seems to make clang fail. Is this possible? I've been reading the clang documentation, and I haven't found it.
As a last resort, there is a brute force option.
Add this to the beginning of a file:
// Omit from static analysis.
#ifndef __clang_analyzer__
Add this to the end:
#endif // not __clang_analyzer__
and clang --analyze won't see the contents of the file.
reference: Controlling Static Analyzer Diagnostics
So, this isn't really an answer, but it worked well enough.
What I ended up doing was building the static library ahead of time, and then building the project using scan-build. Since there was already an up-to-date build of the static library, it wasn't rebuilt and thus wasn't scanned.
I'd still love to have a real answer for this, though.
Finally, in 2018 the option was implemented.
Use --exclude <path> [1] [2] option
--exclude
Do not run static analyzer against files found in this directory
(You can specify this option multiple times). Could be useful when
project contains 3rd party libraries.
I don't use XCode, but using scan-build in linux the following works for me. I my case, I want to run the static analysis on all first party, non-generated code. However, I want to avoid running it on third_party code and generated code.
On the command line, clang-analyzer is hooked into the build when scan-build sets CC and CXX environment variables to ccc-analyzer and c++-analyzer locations. I wrote two simple scripts called ccc-analyzer.py and c++-analyzer.py and hooked them in to the compile in place of the default. In these wrapper scripts, I simply looked at the path of the file being compiled and then run either the raw compiler directly (if I wish to avoid static analysis) or the c*-analyzer (if I wish for static analysis to occur). My script is in python and tied to my specific build system, but as an example that needs modification:
import subprocess
import sys
def main(argv):
is_third_party_code = False
for i in range(len(argv)):
arg = argv[i]
if arg == '-c':
file_to_compile = argv[i + 1]
if '/third_party/' in file_to_compile or \
file_to_compile.startswith('gen/'):
is_third_party_code = True
break
if is_third_party_code:
argv[0] = '/samegoal/bin/clang++'
else:
argv[0] = '/samegoal/scan-build/c++-analyzer'
return subprocess.call(argv)
if __name__ == '__main__':
sys.exit(main(sys.argv))
For Xcode users, you can exclude individual files from static analyzer by adding the following flags in the Target -> Build Phases -> Compile Sources section: -Xanalyzer -analyzer-disable-all-checks