My application contains multiple sub folders, that can go quite deep, e.g.
library\management\security\descriptor\configurations
(this is just a fictive example)
If another part of my application needs an include file of this folder it writes this:
#include "library\management\security\descriptor\configurations\config.h"
The problem is that if the file that contains this include is also in a quite deep path, like this:
people\groups\interestgroups\manager.cpp
And we have checked out our project in the folder:
E:\jenkins\workspace\application\release\flavour
Then the Visual Studio compiler (we compile using the /I. (slash-I-dot) option) first looks for the file in this location:
E:\jenkins\workspace\application\release\flavour\people\groups\interestgroups\library\management\security\descriptor\configurations\config.h"
And then only in
E:\jenkins\workspace\application\release\flavour\library\management\security\descriptor\configurations\config.h"
(this behavior is described in http://msdn.microsoft.com/en-us/library/vstudio/36k2cdd4(v=vs.100).aspx).
So it insists in looking first in the place where the compiled file is, and then only looking at the /I option.
The problem is that the place where the compiler looks first results in a filename that is too long (>256 characters) and the compiler just gives up.
Is there a way to tell Visual Studio to not stop when an include path is too long? Preferably without using the bracket include format (#include <>).
You can just make file in interestgroups folder that only include config.h file and you just include interestgroups file and use that file
Related
In the code I have:
#include "xml/XMLParser.h"
While that actual path to the 'XMLParser.h' is:
${workspaceFolder}/lib/XML/XMLParser.h
This folder structure causes VSCode to be unable to match the include (mismatched capitalization), and thus showing a red squiggle underline and not giving me nice intellisense.
Due to a convoluted build process, the directory gets aliased to its lowercase version during build, which then allows the compiler to find the header as written in the code. Thus, is there a way I can tell VSCode to do something similar when searching for matching includes?
I can't rename the folder name nor can I change the include to match the folder since this code is part of a very large project.
I am a C# developer, and spoiled rotten when it comes to references and dependencies. I am working on a small project now in Visual C++ (Visuial Studio 2017), where I want to use the libtomcrypt and libtommath libraries. I've created a small project and added the 2 projects to my solution:
I have also added my includes:
And I added the dependencies:
However, I still can't build:
Error C1083 Cannot open include file: 'tomcrypt.h': No such file or directory
I am not sure what else I need to do to get the references working and the code to compile. Any pointers is appreciated!
The error message indicates that the compiler can't find the file tomcrypt.h while compiling one of your source files. From the message I would guess that you have a line like the following in your source file:
#include <tomcrypt.h>
(...or perhaps with quotes instead of brackets.) From your screenshot I can see that you've added "...\repos\libtomcrypt-develop\src\headers" to your include path. Is the file tomcrypt.h found directly in that folder, or is it perhaps in a subfolder instead?
Your #include directive will basically append whatever path you give it to each entry in your include path when looking for the file, so if there are subfolders in between, you'll have to expand your #include directive to include those folders.
If this doesn't solve your problem, perhaps try posting the actual full path of where this header file exists on your filesystem, as well as your complete include path value! (The full compiler command from the build log would be useful, as well as the complete error message(s) related to this source file.)
Edit:
The original poster posted a separate answer indicating that the actual problem was that the Visual Studio Project Properties were set correctly, but that he was accidentally trying to build a different Configuration. :(
I was building the project under x86. Once I changed it to x64, it built just fine.
Suppose we have a pretty big amount of files in a project, so writing #include "somefile" to all of them will take a long time, so it there a way to include "somefile" into all files in the project?
If it is visual studio, use the /FI option (force include).
https://msdn.microsoft.com/en-us/library/8c5ztk84.aspx
Some compilers have an option for this. For example, the option for GCC is -include.
-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.
Of course, using such option will make your project depend on the support for such compiler feature. A portable solution is to simply edit all your files.
If you are working with an IDE surely there must be a mechanism of "find and replace" that you can use!
The idea here would be to find a string (another #include for example) that you know that exists in the same place that you want to put the #include's and replace it with your new #include concatenated with a newline and the string that was already there. The trick here is to do it across all files at the same time.
Examples on some common IDE's:
-Visual Studio - Visual Studio Code Replace multiple files at once
-Eclipse - Is there a way to find/replace across an entire project in Eclipse?
-Notepad++ - How To “Find And Replace” Words In Multiple Files
I found the article Where does Visual Studio look for C++ header files? to be a good start, but I have further questions. The general order that VS looks for include files are (1) local directory, (2) those specified with /I, and (3) those specified by the environment (INCLUDE env var or VC++ settings).
Q1. I think that the /X option turns off (3). Right? Or does it also turn off (1)?
Q2. If I have a nested include file (main.c includes inc1.h, which includes inc2.h), where the first included file is found in one of the /I folders, does VS look for the second included file starting in that same /I folder, or just the local folder of the original source file? VS2008 seems to be operating the first way, but I'd like to find it documented somewhere.
The /X option will not disable looking for files in the local directory (assuming you are including them like "this.h" rather than <this.h>). You can easily test this by creating a file
#include "foo.h"
int main() {}
creating an empty foo.h, and compiling using the /X flag.
For Q2, my test with VC2010 showed it behaves the same as VC2008. What I did was had a main:
#include "inc1.h"
int main() {}
with a folder inc that contained an inc1.h that just
#include "inc2.h"
with two different inc2.h files; on in inc and one in the directory with my source file. The one in my source directory was empty, the one in inc had an #error directive. In general, you don't want to rely on this though. Both the C and C++ standards simply say on #include that "the named source file is searched for in an implementation-defined manner".
Q1. The /X option does turn off the INCLUDE var, but not the local directory (see Q2)
Q2. C and C++ compilers, for nested include files, make the location of an include file the current local directory, so you can't turn it off.
eg.
If your inc.h file is found in one of the /I folders and it tries to include a file like this:
#include "foo/foo.h" then it must use its own local directory first, before all the other /I folders as they all might have a foo folder with a foo.h file and your inc.h file would probably not compile as its just included the wrong header file.
I've just found this msdn page for VS2008 which seems to have a complete explanation.
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.