I noticed this little sign on a project source file and didn't know what it meant.
It means the file has been configured to be ignored (not compiled) in the project.
The specific option is called 'Exclude From Build' in the General property.
In addition to Steve's answer, I would add:
Your project/solution may have multilple configurations (Debug/Release, Win32/x64, and other custom configurations like "HighPerformance", "ForMobile", "ManagedDLL"), and you may like not to have set of source files get compiled. For, this you may put them into "Excludes".
To put into exclusion, just select the source file (.CPP, .C), open property page for it, and set "Excluded from Build" to Yes. To make it part of build process (i.e. let it compile), set this property to No.
Header Files need not to be put into exclusions, as they wont be compiled by compiler, it is just for programmer's view. Headers are only compiled when some source file do include them.
Related
I have a C++ project built of several shared libraries. Each library source code is placed under its subtree of directories. The main CMakeList file contains a list of add_subdirectory(<dirname>) directives. CMakeList files in every subdirectory contain definitions like the following:
set (SOURCE_FILES
util/src/Connector.cpp
pub/util/Connector.h
)
add_library(channels SHARED $( SOURCE_FILES))
SET_TARGET_PROPERTIES(channels PROPERTIES LINKER_LANGUAGE CXX)
where channels is the subdirectory name.
Although the search path for include files is set correctly and compilation works, KDevelop does not see the Connector.h header file and, therefore, its parsing and code/class browser do not work.
I know that .kdev_include_paths file in every directory might solve the problem. Unfortunately, this approach may not be used due to some additional constraints in our development environment.
Is there any other way to solve this issue?
I use Intel C/C++ compiler on RHEL 7.1 with KDevelop 5.0.4 running from AppImage.
I found and solved a problem which presented similarly - header files not seen and code/class browser failing. The cause turned out to be an error in my code. For the benefit of others who may write a similar bug and arrive at this page, here is what I did wrong:
I had a header only class in a file 'myClass.hpp' and an empty implementation 'myClass.cpp'. My CmakeLists.txt cited the implementation, but my implementation did not contain #include "myClass.hpp". The effect in Kdevelop-5.1.0 was that the header file was not parsed as part of the program - hence its includes were not read, and much of the code failed semantic analysis.
On KDevelop 5 this solved my issue:
Go to menu "Project" -> "Open Configuration..."
In the window which now opens, go to "Cppcheck" on it's left side and then to "Include Directories" on it's right side
check the "Use 'system' include dirs" option:
Try adding
include_directories(${SOURCE_FILES})
It appears I experienced the same problem.
Symptoms:
-- Kdevelop 5.1.2 could not find some #includes; they were underlined in source files.
-- There was no problem building the project
Cause:
-- Both symbolic links and the original *.h files were in the paths specified in
include_directories( ) in CMakeLists.txt. Symbolic link removal fixed the problem.
Kdevelop is probably right to be confused about multiple *.h files with the same name.
Maybe some future Kdevelop release will be able to recognize that it is dealing with only one target.
I have a C++ program that I'm building with Clang 3.9's profile-guided optimization feature. Here's what's supposed to happen:
I build the program with instrumentation enabled.
I run that program, creating a file with profile-data: prof.raw.
I use llvm-profdata to convert prof.raw to a new file, prof.data.
I create a new build of that same program, with a few changes:
When compiling each .cpp file to a .o file, I use the compiler flag -fprofile-use=prof.data.
When linking the executable, I also specify -fprofile-use.
I have a Gnu Makefile for this, and it works great. My problem arises now that I'm trying to port that Makefile to CMake (3.7, but I could upgrade ). I need the solution to work with (at least) the Unix Makefiles generator, but ideally it would work for all generators.
In CMake, I've defined two executable targets: foo-gen and foo-use:
When foo-gen is executed, it creates the prof.raw file.
I use add_custom_command to create a rule to create prof.data from prof.raw.
My problem is that I can't figure out how to tell CMake that each of the object files depended upon by foo-use has a dependency on the file prof.data.
The most-promising idea I had was to (1) find a way to enumerate all of the .o files upon which foo-use depenends, and then (2) iterate over each of those .o files, calling add_dependency for each one.
The problem with this approach is I can't find an idiomatic way, in my CMakeLists.txt file, to enumerate the list of object files upon which an executable depends. This might be an open problem with CMake.
I also considered using set_source_files_properties to set the OBJECT_DEPENDS property on each of my .cpp files used by foo-use, adding prof.data to that property's list.
The problem with this (AFAICT) is that each of my .cpp files is used to create two different .o files: one for foo-gen and one for foo-use. I want the .o files that get linked into foo-use to have this compile-time dependency on prof.data; but the .o files that get linked into foo-gen must not have a compile-time dependency on prof.data.
And AFAIK, set_source_files_properties doesn't let me set the OBJECT_DEPENDS property to have one of two values, contingent on whether foo-gen or foo-use is the current target of interest.
Any suggestions for a clean(ish) way to make this work?
Discussion on author's idea #1
The most-promising idea I had was to (1) find a way to enumerate all of the .o files upon which foo-use depenends, and then (2) iterate over each of those .o files, calling add_dependency for each one.
This shouldn't work according to the documentation for add_dependencies, which states:
Makes a top-level depend on other top-level targets to ensure that they build before does.
Ie. You can't use it to make a target depend on files- only on other targets.
Discussion on author's idea #2
I also considered using set_source_files_properties to set the OBJECT_DEPENDS property on each of my .cpp files used by foo-use, adding prof.data to that property's list.
The problem with this (AFAICT) is that each of my .cpp files is used to create two different .o files: one for foo-gen and one for foo-use. I want the .o files that get linked into foo-use to have this compile-time dependency on prof.data; but the .o files that get linked into foo-gen must not have a compile-time dependency on prof.data.
And AFAIK, set_source_files_properties doesn't let me set the OBJECT_DEPENDS property to have one of two values, contingent on whether foo-gen or foo-use is the current target of interest.
In the comment section, you mentioned that you could solve this if OBJECT_DEPENDS supported generator expressions, but it doesn't. As a side note, there is an issue ticket tracking this on the CMake gitlab repo. You can go give it a thumbs up and describe your use-case for their reference.
In the comments section you also mentioned a possible solution to this:
Potential other solution a) double project system where main user invoked project forwards settings to second pgo project compiling same settings again.
You can actually put this into the CMake project via ExternalProject so that it becomes part of the generated buildsystem: Make the top-level project include itself as an external project. The external project can be passed a cache variable to configure it to be the -gen version, and the top-level can be the -use version.
Speaking from experience, this is a whole other rabbit hole of long CMake-documentation-reading and finicking sessions if you have never manually invoked or done anything with ExternalProject before, so that answer might belong with a new question dedicated to it.
This can solve the problem of not having generator expressions in OBJECT_DEPENDS, but if you want to have multi-config for the top-level project and that some of the configs in the multi-config config not be for PGO, then you will be back to square one.
Proposed Solution
Here's what I've found works to make sources re-compile when profile data changes:
To the custom command which runs the training executable and produces and re-formats the training data, add another COMMAND which produces a c++ header file containing a timestamp in a comment.
Include that header in all sources which you want to re-compile if the training has been re-run.
If you want to support non-PGO builds, wrap the timestamp header in a header which checks that it exists with __has_include and only includes it if it exists.
I'm pretty sure with this approach, CMake doesn't do the dependency checking of TUs on the profile data, and instead, it's the generated buildsystem's header-dependency tracking which does that work. The rationale for including a timestamp comment in the header file instead of just "touch"ing it to change the timestamp in the filesystem is that the generated buildsystem might detect changes by file contents instead of by the filesystem timestamp.
All the shortcomings of the proposed solution
The painfully obvious weakness of this approach is that you need to add a header include to all the .cpp files that you want to check for re-compilation. There are several problems that can spawn from this (from least to most egregious):
You might not like it from an aesthetics standpoint.
It certainly opens up a hole for human-error in forgetting to include the header for new .cpp files. I don't know how to solve that.
You might not be able to change some of the sources that you need to re-compile, such as sources from third-party static libraries that your library depends on. There may be workarounds if you're using ExternalProject by doing something with the patch step, but I don't know.
Unfortunately I don't know how to solve any of those problems. For my personal project, #1 and #2 are acceptable, and #3 happens to not be an issue.
how to include certain header files by default so that i don't have to type them in every programs:
In dev c++ and code::blocks
Make a global header file that in turn includes whatever files you need in every project, and then you only have to include that single file.
However I would recommend against it, unless all your different project are very similar. Different projects have different needs and also need different header files.
You could issue a compiler directive in your project file or make script to do "per project" includes, but in general I would avoid that.
Source code should be as clear as possible to any reader just by its content. Whenever I have source code that dramatically changes its semantics, eg. by headers that are unknown to me, this can be quite confusing.
On top of that, if you "inject" those headers for certain compilation units that don't need them, that will negatively impact compile time.
As a substitution, what about introducing a common.h/hpp header that includes those certain header files? You can then include your common header in all files that need them and change this common set of headers for all depending files at once. It also opens the door to use precompiled header files, which may be worth a look for you.
From GCC documentation (AFAIK GCC is default compiler used by the development environment you are citing)
-include file
Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for
file is the preprocessor's working directory instead of the directory
containing the main source file. If not found there, it is searched
for in the remainder of the #include "..." search chain as normal.
If multiple -include options are given, the files are included in the order they appear on the command line.
-imacros file
Exactly like -include, except that any output produced by scanning file is thrown away. Macros it defines remain defined. This allows you
to acquire all the macros from a header without also processing its
declarations.
All files specified by -imacros are processed before all files specified by -include.
But it is usually a bad idea to use these.
Dev c++ works with MingW compiler, which is gcc compiler for Windows. Gcc supports precompiled headers, so you can try that. Precompiled headers are header files that you want compiled and added to every object file in a project. Try searching for that in Google for some information.
Code::blocks supports them too, when used with gcc, even better, so there it may even be easier.
If your editor of choice supports macros, make one that adds your preferred set of include files. Once made, all you have to do is invoke your macro to save yourself the repetitive typing and you're golden.
Hope this helps.
Is there a way to set Visual Studio solution parameters so it just create precompiled headers without building whole solution.
Specifically, it is a huge c++ solution with many projects in itself.
Thank you.
Only select the pch creator source file (usually stdafx.cpp), and compile that (Ctrl-F7, or right-click it and select 'Compile')
More info since it doesn't seem to be working for you:
In every project that uses a precompiled header, there is one source file that is used to create the pch file, and the rest only use the pch file. This source file usually only consists of one line:
#include "StdAfx.h"
"Stdafx.h" is the default precompiled header file name in Visual C++, it could be something else for you. If you compile "StdAfx.cpp" by itself, that generates a file with the name "Your_Project_Name.pch" (again, that's only the default). You should see it in the intermediate directory, the same one where all the obj files are. This is the precompiled header. If you did like I said, and selected 'Compile' and not 'Build', then no other files will be compiled, and no linking will take place.
If that still does not solve your problem, then I have no idea what you are asking.
Here's an article describing the benefits and how to set it up.
If you have larger projects, it is definitely worth the few clicks and the extra disk space.
The article says you need to add stdafx.h to all sources and headers; it's not correct. It's sufficient to add to sources - make sure it's the first line though as everything before it will be ignored.
The article does not mention it, but you'll be getting errors from sources that do not include the stdafx.h. You have a choice to resolve this error: you either add it, or exclude the source(s) from the precompilation process.
To exclude source files:
select source file(s) in the solution explorer; yes you can select more at once,
right click on the highlighted source file,
click properties from the pop-up menu,
select 'All configurations' from the combo-box on top,
under C-C++ configuration click 'Precompiled headers',
on the right-hand side select 'Not using precompiled headers',
click apply,
click ok.
Enjoy your new builds in a few seconds from here on (the first build will take longer).
If you right-click any Cpp files except stdafx.cpp from your project and set Excluded from build to Yes, it will only generate the precompiled header.
You can achieve the same result through the command line or if you create new project containing only your stdafx.cpp
I have a situation where another developer is including source files from a project that I maintain in a project that he maintains. The nature of the files is such that each source file registers a "command" in an interpretive environment so all you have to do is link in a new source file to register a new "command". We can't put these files in a static library because, unless the project makes explicit reference to the symbols in the file, the linker will optimise the file away.
It seems like a potential solution is to have a file external to both projects that "includes" a list of source file names in both projects. The problem is that I have no idea whether or how this could be done. Suggestions, anyone?
There is no reason a source file can't be in multiple projects. Just add it as an 'existing item' in VS.
If you are using precompiled headers then both projects will need equivalent set ups for this to work.
You can also use a #pragma in a lib to force a symbol to be included when the linker would otherwise discard it.
#pragma comment(linker, "/include:__mySymbol")
See the MSDN document for #pragma comment and the include option
Could you simply write a source file containing nothing but #include directives? I'm not sure if VS checks whether the dependent files have changed if they're not in the project proper, though.