Using PC-Lint, I'm attempting to make a header file be treated as a library header so that I can suppress messages from inside it. I'm using the library module option +libm(module.c) which should treat module.c as a library module and any headers it includes (i.e module.h) as library headers as described in section 6.1 of the PC-Lint manual for v9.00. Naturally, module.h is also included in my source files which are not library modules.
The problem is that when I lint the code, I still get messages from module.h even though I provided the +libm(module.c) option. I suspect this is because the module.h file is included in my other non-library modules. But such a situation is a typical use case and so this makes this +libm option useless. I know I could use +libh(module.h) or +libdir(...) but I want +libm(module.c) to work properly for me. Any suggestions?
It is not presented like that in the manual, but my experience shows that not all header files included by the library module are considered library. They cannot be: What if the module includes your own header files, the header files you want explicitly to be processed?
Use the Lint option -vf (caution: large output!) to see how Lint interprets your header files. Library files are designated as such.
The ones missing can be added using the normal -lib* option set.
Related
GCC allows for having command-line options passed by a file by #file syntax. Using this the file should be added as prerequisite (aka dependency) to the target.
I'm not finding any reference in CMake docs about argument files, suggesting it's not supported. Or perhaps just takes a little bit more plumbing, e.g. cat file|xargs? Or some way telling CMake explicitly that the file is a prerequisite? I mean "Prerequisite" according to GNU Make terminology. If file contents change I have to rebuild. AKA dependency.
Which is it? And how does it work?
You should just be able to use target_compile_options() or CXX_<LANG>_FLAGS like you normally would.
Since the flags available for different compilers are usually different, you probably will have one for each compiler you support, in which case you can wrap your target_compile_options() calls with if() blocks based on CMAKE_CXX_COMPILER_ID or the MSVC variable, or use the CXX_COMPILER_ID or X_COMPILER_ID generator expressions to use the right file (if you have multiple files for multiple compilers) for the right compiler.
However, I've also noticed before when trying this that using file flags like this doesn't automatically add the file as a dependency to the target (the CMake won't add a rule for the target to rebuild if that file changes), so you might need to do that manually like this:
# wrap this in a function taking `target` as an argument.
get_target_property(sources ${target} SOURCES)
set_property(SOURCE ${sources}
# DIRECTORY "${PROJECT_SOURCE_DIR}" "${PROJECT_BINARY_DIR}"
TARGET_DIRECTORY ${target}
APPEND PROPERTY OBJECT_DEPENDS "${PROJECT_SOURCE_DIR}/path/to/flags/file.txt"
)
The above snippet courtesy of a user in this GitHub issue. It uses the OBJECT_DEPENDS source file property to make every source file of a target depend on the compiler options file. I (and the author of that code snippet) would classify it as a workaround, since it only works for Generators that support OBJECT_DEPENDS. From the CMake docs:
Specifies a semicolon-separated list of full-paths to files on which any object files compiled from this source file depend. On Makefile Generators and the Ninja generator an object file will be recompiled if any of the named files is newer than it. Visual Studio Generators and the Xcode generator cannot implement such compilation dependencies.
I'm not sure at what level of the toolchain it would be best to request that such automatic dependency-tracking functionality be added. According some of the Ninja buildsystem maintainers in the above linked GitHub issue, (if my noob brain is understanding the words they're saying correctly :P), it's something that could be handled by compilers when they generate depfiles given a compile comand for a source file. I'm currently too scared to ask compiler maintainers if that's the case. If you're interested in digging onto the part that CMake plays in orchestrating other tools to get dependency tracking for things like header files and the creation of dependency-tracking files ("depfiles"), you can go to your CMake installation's Modules folder and grep for CMAKE_DEPFILE_FLAGS_. Then use "find in files" at https://github.dev/Kitware/CMake.
Notes: Visual Studio / MSVC's compiler calls these "command files", gcc doesn't seem to have a particular name for them, and clang calls these "configuration files". They all support similar #file syntax. I'm not sure what the history is with that, but many compilers aim to have levels of compatibility (similar interface to) with GCC.
That's all. If you're bored and want to read a bit about how CMake does header dependency detection (which is loosely related here on the topic of depfiles), see this other post of mine.
I've successfully used CMake to built a shared library, but the size is not so good.
I've already tried several compile flags to cut size, etc.
set_source_files_properties(${TARGET_SOURCE_FILES} PROPERTIES COMPILE_FLAGS "-fexceptions")
Code above is used to open exception handling for single file while -fno-exceptions is added to CMAKE_CXX_FLAG. It works fine.
However, I used the same code to an *.hpp to open rtti for it while -fno-rtti is added to CMAKE_CXX_FLAGS. Unfortunately, it didn't work.
So, is there a way to add COMPILE_FLAGS to header files in CMAKE? I've viewd documentary on offical site, but still no clues.
This is not possible and probably a questionable thing to do in the first place.
Mixing different compile flags within the same binary is a dangerous game. Usually you would want all compilation units in a target to share the same compile flags, as it is very easy to mess things up subtly but terribly otherwise. However, CMake still allows you to use source file properties the way you did to do this if you are really sure what you are doing.
With header files though, things are worse. Headers do not get compiled on their own, so what you are asking for is that all source files that pull in that header will inherit the special compilation options associated with that header. But since all calls to the compiler happen based on source files, this would require to re-run CMake on every source change, check all the includes in all the source files, and adapt the compiler options accordingly. Hopefully you can now see why CMake doesn't want to do this.
What you can do though is specify those options on a per-target basis. Move your headers to an interface target and add a corresponding interface property there. Then, all targets that want to use the header will have to pull in that target as a dependency. As a consequence, all depending source files will get the special compile flags, regardless of whether they actually do include the header or not, but that's just how build systems work:
add_library(my_headers INTERFACE)
target_include_directories(my_headers INTERFACE ${PATH_TO_HEADERS})
target_compile_options(my_headers INTERFACE $<$<CXX_COMPILER_ID:GNU>:-fexceptions>)
add_executable(client a.cpp)
target_link_libraries(client PUBLIC my_headers)
In this example, a.cpp (as well as all other sources of client) will now get compiled with the -fexceptions flag.
We are using flexelint for statical analysis on our code base. When running flexelint, we are seeing lots of errors in standard C/C++ headers, our standard headers are in a non-standard location. We would like to skip standard headers being processed by flexelint. Also we would like to skip other headers coming from a thirdparty directory.
If you lint a single file or only a part of your project, you should use the -u option. This suppresses warnings in header files that are related to inter-project problems.
I have a dll file, irig106.dll, that I produced from a compile in Visual Studio 2010. (The source code is here). Notice the multitude of .h files in there; the main one is called irig106ch10.h, as far as I can tell.
I would like to import it into MATLAB via loadlibrary. I put all the .h files into their own folder, called "headers". Here's what I get:
loadlibrary('irig106.dll', 'headers\irig106ch10.h', 'addheader', 'config', 'addheader', 'stdint', 'includepath', '.\headers');
Warning: Warnings messages were produced while parsing. Check the functions you intend to use for correctness. Warning text can be viewed using:
[notfound,warnings]=loadlibrary(...)
Error using loadlibrary (line 418)
There was an error loading the library
"mydir\irig106.dll"
mydir\irig106.dll
is not a valid Win32 application.
So I'm not sure of a few things:
Why is loadlibrary claiming that the dll is not a valid Win32 application? It looks like based on my Visual Studio settings, I am compiling for Win32.
Per the loadlibrary documentation, I need to explicitly use addheader for each header file I want to include, and those headers need to be #included in the base header file. In this case, I only include config.h and stdint.h in irig106ch10.h but I'd like to use all those other headers. Do I need to make a "header header" file where I include everything?
I guess I'm looking for a tutorial on how to use loadlibrary for complicated dlls with multiple headers like this, because there really isn't much in the way of examples on the internet. I'd love to see someone build the .dll (uncomment the #define IRIG_NETWORKING in config.h) and give a step-by-step.
I have a header file MyHeader.hpp that includes a bunch of header files form an external code project. The header files from the external project throw a lot of warnings, which I don't want to see, because I'm not working on that code.
I have precompiled MyHeader.hpp and I have verified that GCC is actually using the precompiled header by moving the original MyHeader.hpp file, so that it would not be found if GCC tried to use it instead of the precompiled header file MyHeader.hpp.gch. This works and it speeds up the compilation process a little bit (but not as much as I had hoped).
But: I am still seeing all the warnings produced by the files from the external code. Why do I see those warnings? I thought that GCC would not actually parse the header files that are precompiled and I've verified that it is using the precompiled header file, so why does it display the warnings from that header file?