In building a my application, I have a fairly long list of *.Lib files required for compilation. Here is my compilation instruction:
Bin\cl.exe Main.cpp /EHsc /I atlmfc\include /I Includes /I Includes\Winsdk atlmfc\lib\amd64\nafxcw.Lib Libs\libcmt.lib Libs\Kernel32.Lib Libs\User32.Lib Libs\Gdi32.Lib Libs\MSImg32.Lib Libs\ComDlg32.Lib Libs\WinSpool.Lib Libs\AdvAPI32.Lib Libs\Shell32.Lib Libs\ComCtl32.Lib Libs\ShLwApi.Lib Libs\Uuid.lib atlmfc\lib\amd64\atls.lib Libs\Ole32.Lib Libs\OleAut32.Lib Libs\oldnames.lib Libs\WS2_32.Lib Libs\MsWSock.Lib Libs\OleAcc.Lib Libs\comsuppw.lib Libs\GdiPlus.lib Libs\Imm32.Lib Libs\WinMM.Lib Libs\MsXml2.Lib Libs\OleDlg.Lib Libs\Urlmon.Lib /link/SUBSYSTEM:WINDOWS
All of these files are in the same directory. Well, one or two directories anyway. Is there some way that I can just tell the compiler to look in those directories for files that it needs, instead of typing out every single one?
Are you looking for http://www.lavishsoft.com/wiki/index.php/Visual_Studio_Paths or http://msdn.microsoft.com/en-us/library/1xhzskbe(v=vs.80).aspx? As already explained by Roman R. you can use the pragma command afterwards in your files. This way you can always see which libs are required without looking at the project configuration. If you don't want to use the pragma command there should be a linker section in your project configuration where you can add the libs.
Related
I'm (cross-)compiling a shared C library with support for many different platforms which is handled by an hierarchy of CMakeLists files. In those files, several platform specific compiler flags are conditionally produced (with add_definitions()). I can successfully compile and link the source code leading to an appropriate .so file.
But to use the library in any project, I need to provide the right header files, too. The following install command of CMake selects the right header files to copy but does not apply the replacement of preprocessor defines/includes:
install(FILES ${headers} DESTINATION include/mylibrary)
So how can I generate/install the "post-compiled" header files?
What I thought of so far:
As add_definitions() should stack my -D's in the COMPILE_DEFINITIONS variable, maybe running a foreach loop on the copied raw headers and replace the define/include placeholders?
Using add_custom_command() to apply some logic before copying?
Edit: As pointed out by Tsyvarev, there is an answer quite near to my needs here, but unfortunately not quite it. In summary, the answer gives 2 options:
Include a special 'config' header in all of the library's headers and leverage the cmakedefine command to call configure_file() on this header. I can't use this approach because I don't want to alter the library headers.
Create a target-specific .cmake file which helps external projects in including the right headers together with all necessary -D defines. I can't use this approach either, because my external projects do not use cmake for building. Plus, I wish to create a library that is as easy to include as possible.
Any other thoughts?
Edit 2: I may have to elaborate on my statement, that the install command of CMake is not replacing defines. Take the following example:
//sampleheader.hpp
#ifndef SAMPLEHEADER_HPP_
#define SAMPLEHEADER_HPP_
#include OS_SPECIFIC_HEADER
//...
Now I have a CMakeLists.txt file that does something like this:
# ...
if (${OS} MATCHES "arm-emblinux")
add_definitions(-DOS_SPECIFIC_HEADER="emblinuxHeader.hpp")
elseif (${OS} MATCHES "linux")
add_definitions(-DOS_SPECIFIC_HEADER="linuxHeader.hpp")
endif()
# ...
Everything compiles fine, but when the install command above gets called, I have a header file in my ../include/ directory still with OS_SPECIFIC_HEADER placeholder in it. And of course, this cannot be properly included in any development project.
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.
I am looking for a straight forward way to use precompiled headers for a C++ project using Eclipse / CDT. The stuff does work when running from command line but I am looking for an easy way to integrate it into Eclipse.
Any suggestions ?!
Just to help others who may stumble upon this (since i spent some time figuring this out)
The first thing to do is create a PCH folder (if you want) with a pch.cpp and pch.h file.
pch.cpp: (this file is to compile the .gch)
#include "pch.h"
pch.h:
#include <iostream>
#include <string>
// more stuff that's not changing anytime soon...
The second thing to do is create a PCH build configuration.
exclude all your project source files from this build. (we only need to compile pch.cpp)
select the files/folders > Right Click > Resource Configurations > Exclude from Build > PCH
Now we need to make it compile as a .gch (precompiled header)
pch.cpp > Right Click > Properties > C/C++ Build > Settings > Tool Settings
Compiler > Pattern: ${COMMAND} ${FLAGS} ${INPUTS} (remove all the output stuff)
Misc > Flags: -c -x c++-header -o "../src/PCH/pch.h.gch"
Now when you build with this configuration, it'll produce the pch.h.gch where pch.h is.
(it'll also give a meaningless error trying to create an exe. just ignore that)
Back on the normal Release build, exclude pch.cpp since you don't need to compile that.
Now it's time to test the .gch is being used over the .h
at the top of pch.h put #error "not using precompiled header file"
The .ghc is only used if the header is included first, in the compiling file.
"Only one precompiled header can be used in a particular compilation."
you should precompile different selections of headers best fit for different compilation units
COMPILE TESTS
without precompiled headers
took 34s.189ms output src=2,143,078 bytes exe=1,346,864 bytes
with -include ../src/PCH/pch.h (included in every compilation unit) (only the pch.h not the .gch)
took 48s.364ms output src=2,159,431 bytes exe=1,355,298 bytes
(this is why we #include manually where needed so it should still take around 34s to compile without .gch)
with -include ../src/PCH/pch.h and pch.h.gch (fast compilation, but still inefficient with -include)
took 22s.535ms output src=2,159,431 bytes exe=1,355,298 bytes
if the pch's are organized/utilized properly (correct choice of headers and files to include them in) (not used in every file) it should be much faster than 22s. (this test was just done on a project which weren't built with pch's in mind)
additional speedup which can triple compile time
Project > Properties > C/C++ Build > Behavior > Enable parallel build
From what i've seen, currently Eclipse CDT doesn't support precompiled headers directly. I mean, you can't set an option like : "For this header, compile it". The same applies for headers of external libraries of your eclipse project.
As you know, you need to set the same compilers flag for the header compilation in order to get the compiler use it for the other compilation unit. (At least in the case of GCC).
So, you have several solutions :
You replace the default build command found in "Properties for -> C/C++ Build -> Builder Settings -> Build command" with a custom script that will modify the makefiles generated by eclipse and then call make. A ruby solution is proposed here. Note, that it doesn't allow the use of multiple precompiled headers.
You can use ccache instead of using GCC. It detects when the same compilation is done again, so it's a bit different from using precompiled headers.
EDIT :
To get the ruby script working, you need to have at least one .cpp file inside the same directory as your header file. Otherwise you'll get an error on a missing file "subdir.mk".
Another approach is to create a source file (e.g. pch.cpp) with build settings changed to create the precompiled header. It should be included in the build in order to create the precompiled header, and then excluded in order to build the final executable. It needs to be temporarily reincluded if the header file is changed.
This website provides more details, including a way of creating different precompiled headers for each build configuration.
Consider using cmake and cotire
I am trying to make a setup as described in my previous question: Any way to parse preprocessed source through external tool before it compiles?
All of my .cpp files are set to compile with /p, which generates .i (preprocessed) files for all of them, but no object files. Those generated .i files are also added to my project, and an external build tool option is set to my tool that modifies those files, and saves them under new extension, .obfuscated.cpp
All those .obfuscated.cpp files are also added to the project, and are set to compile normally, producing object files.
Now the problem is that Visual Studio (or the linker, someone of them) for some reason want the obj files both from .cpp files (which now are just saved to .i files, no object files produced), and from .obfuscated.cpp (which are created normally).
I would assume that the linker would not require .obj files from sources that are set to compile with /P option, because, well that option prevents object files from being created.
Now I only see two ways to solve this:
1) Do the build in two steps. In the first one make sure all the .cpp files are preprocessed and saved to .i files. This build does not have to complete, just has to save .i files. Then after that, I select all the .cpp files and set them to "Exclude from build", then everything compiles as it should.
2) Instead of adding the files to the project and using the external build tool option, make a pre-link step instead, in which my own tool would automatically find all the .i files (could take all *.i in a certain directory), process them to *.obfuscated.cpp, and then manually call cl.exe on all of those files to produce object files, rename them to proper names (so that the linker thinks they are object files created from original sources) and put into intermediate directory. But in this case I would have to keep track of all the compiler arguments and change them accordingly if something changes in my project...
Both of these solutions don't seem very beatuful. Is there some other way to do this in Visual Studio? Can't I just tell the linker to ignore missing .obj files? (All the symbols will be found anyway...)
maybe this can help you : instead of the extension .obfuscated.cpp give it an simpler extension like .icpp and add those .icpp files (after first compile) to your project (in a separate folder in your project) ,then for each of those .icpp files goto their property-page and set the correct build-tool (C\C++ compiler) and your .obj files retain the same name-part as your original .cpp files so linking should automatically be done correctly.
I had a similar problem.
I just wanted to see the result of the preprocessing (no extra external tool or so).
I ended with the following solution:
I create an empty object file: just add an empty source "dummy.cpp" to your project.
NOTE: dummy.cpp must be empty, otherwise the Linker will complain about
duplicate symbols.
I mark the "*.icpp" sources as "C++-Compiler" and /P
as mentioned above.
I create a PreLink action, containing a
copy $(IntDir)dummy.obj $(IntDir)xyz.obj
for each "xyz.icpp" source.
if you want both compiled and precompiled output:
add a xyz-wrapper.cpp for each xyz.icpp.
The wrapper should contain only one line like this:
#include "xyz.icpp"
Now the Linker still searches for the xyz-objects, which are still not created, but we give it the empty dummy objects.
NOTE: to get Syntax-Highlighting for the *.icpp files in VisualStudio, you should add this extension at ->Tools->Options->TextEditor->FileExtensions
From this thread
http://www.codeguru.com/forum/showthread.php?p=1863547
It seems this cannot be done with:
#pragma comment(linker, "/out:mycool.exe")
Is there some simple way this can be done without having to use project settings, make files etc?
Added:
Why do I want to do this.
Well this gets into another subject which is probably my next question - working with the IDE.
I have to provide many examples in one project. They are simple single files that demonstrate different ways of doing things and each one should really be a different executable EXample1.exe, Example2.exe.
I only want to paste the source code or hand someone a SINGLE file with everything needed to make the example executable (on a web forum for example. I do not want to attach a 3.6MB project folder just to get a different executable name!
Compiling transcends source code. Source code only exists, and something has to take it and make something of it. Anything you do in source code is really just going to be a directive to the compiler. You might as well use project settings. This stuff isn't standard, because the standard only covers behavior and definitions of source code, not compilers.
g++ takes the output file as a parameter: g++ -o myexe.exe main.cpp. What should it do if it comes across a "output should be this!" directive in the source code?
Same with cl (Visual Studio), it passes the output setting into the command line.
Not to say it's impossible, but I doubt it's worth it to try and come up with a way to do it, let alone make it standard.
To use the linker pragma comment, the output file must NOT be specified in the linker section of the project properties:
project -> properties -> Linker -> General -> Output File
Delete the entry: $(OutDir)\$(ProjectName).exe
then the prama statement will work:
pragma comment(linker, "/out:mycool.exe")
Thanks to JC for the walkthrough
Specifying a complete path is not possible
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/11a06ecd-dcca-4d81-8626-ba0c5a1835c1/
but the work around is:
What I do is have a header file loacated somewhere near the library file, this header will include the pragma line.
pragma comment(lib, FILE "../libs/mylibary.lib")
if FILE is "C:\Project\SharedLibs\Xvid\latest.h"
then the pragma will include
"C:\Project\SharedLibs\Xvid\libs/mylibary.lib" once it has normalized the uri to remove the ..'s
this will always cause the pragma to include the library with an absolute path created from the path of the accompanying header.
I use this system to include a single header in a project and regardless of the relative paths between the lib and project the lib will always be included cleanly.
Added:
The full path can be specified as long as it is 8.3 format. This can present problems for a path like:
C:\Program Files\Abyss Web Server\htdocs\
Program files is commonly Progra~1
but a folder name with a space is more tricky. In this case it becomes AbyssW~1
The \ must be escaped resulting in \ producing a working pragma of:
#pragma comment(linker, "/out:C:\\Progra~1\\AbyssW~1\\htdocs\\MyApp.exe")
as kibibu showed:
#pragma comment(linker, "/out:\"C:\\Program Files\\Abyss Web Server\\htdocs\\MyApp.exe\"")
also works
If you don't want to stray too far from a stock Visual C++ installation, you should consider using NMake. It can integrate with the IDE using project files, but it can also simply be run from the command-line very easily. It's also far more lightweight than project files for generating an arbitrary number of simple and similar executables.