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?
Related
It is almost impossible to try increasing the warning level, or using -Werror when working in a large project with many groups developing smaller pieces, and maintaining large amount of legacy code: there are always too many warnings coming from some headers that belong to some other groups that render the whole thing unusable.
The [bad] workaround everybody seems to be abusing is to replace the -I headers search path option with -isystem for all the headers that are in the project, but belong to "some other groups"... This is bad because, while it avoids getting lost in warnings from those "external-headers", that also exclude those from the dependency file generated by gcc, which can lead the build system to not know what to recompile when some project header is updated.
Using gcc/g++, is there a way to do all of the following at once:
exclude true system headers both from reporting warnings and from being included in dependency generation;
exclude some project headers from specific directories from reporting warning, but still include them in the dependency generation;
for all other header: both report warning and include them in the dependency generation;
all while generating the dependency file and building the object file for a given source C/C++ file in one single command?
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.
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.