So in VS 2012, I've created a static library that i want to use in another project. When I try to use the library, I get errors trying to compile using the source files
"fatal error C1083: Cannot open source file: '<file used in library>.cpp':
No such file or directory
I feel like I'm missing something simple to make it work the way I want but I can't wrap my head around the way to do it.
Also, this may be irrelevant, but is there any automated way to combine headers to a single .h file to use for a library?
It looks like you're adding .cpp files from the library to your project. That's not the way to use a static library, instead add the library's .lib file (with the full path) in Configuration Properties | Linker | Input | Additional Dependencies, and then just add #include directives in your project's files to include any headers from the library you need to use.
Related
I'm trying to make a cross-platforms crypto library in C++ at https://github.com/haithngn/cryptor something like https://github.com/MailCore/mailcore2
The Structure is:
Can I make any header files can be include in the statements like this:
#include <Cryptor/MD5Encryptor.h>
I can include these header directly from absolutely file path
../core/CryptorCore.h
But these format will make the source code cannot build succeed in an XCode Project.
I tried to simulate the MailCore2 but that's very difficult.
Hope you can suggest me any solution or do a favor PR on my Repository.
Thanks,
You need to have a proper hierarchy. First, no, you can't have
#include <Cryptor/MD5Encryptor.h>
with your current setup, not while building the library, and not without flattening the hierarchy when installing your files (which CMake can do).
What you can do is:
#include <Cryptor/core/abstract/MD5Encryptor.h>
if you add your project inside a Cryptor folder instead of being at the root of your project.
I would advise you to create a Cryptor.cmake file that would allow people to pick up your library once installed, so that they don't have to know where the library includes are or what the libraries name is.
It should not be necessary to point to every single header file. Just add all directories containing these header files with include_directories(PATH_TO_HEADERS).
For the include of the header file src/core/CryptorCore.h with
#include "CryptorCore.h"
you have to point to
include_directories(${PROJECT_DIR}/core/)
I tried to shorten down my question (the Old question can still be found below)
My current directory structure looks like this
C:\users\documents\projects
|
+----- utility
| |
| +----- include (files not shown)
| +----- src
| |
| +----file1.c (and other files not shown)
|
+----- proj1
|
+----- include (files not shown)
+----- src
|
+----- proj_file1.c (and other files not shown)
I can include the .h files from ..\utility\include with #include <file.h> to proj1, if I add this directory as include path to my IDE (in proj1). Is there an aequivalent solution for the ..\utility\src files? I am using LPCXpresso IDE on Windows 7. I suppose there is the same solution on any IDE, so I just want to know how this whatever path (where .c files will be searched, if not found in the .\src directory) is generally called to find it in my project settings.
I try to avoid using libraries (.lib, .dll)
I don't want to copy the .c files in each project (proj1, proj2, ..., projn)
I want to be able to simply edit the .c and .h files and if recompiling proj1 and so on the changes will be applied, as they will for all other projects
Generating an own makefile may be a solution (but shouldn't there be an Option to add a source-file-path in IDEs?)
#include <..\utility\src> is a non-desired solution as changes to the directory will fource to add this line in each single file, where changing a path in the Options are only some clicks.
Thanks in advance and thanks for the answers up to now
Old Version of my question:
Motivation: Imagine, you write a program in C/C++ in some IDE and have .c and .h source code files as usual. In addition you have a helper.c and helper.h file, were you defined some useful, not project related functions (which can be used in several projects). You want to include these files, but don't want to have them were you store your project related source code.
As far as I know .h files can be stored in a separate folder, which is pointed to by the includepath. This path can be set in every IDE. Further it changes the
#include "helper.h"
statement to
#include <helper.h>
If I put the .c files in the same folder and not include them separately, the compiler will not find them. If I include them as well with
#include <helper.c>
a multiple inclusion will lead to multiple function deklaration and therefore to a compiler-error. Only solution may be an
#ifndef helper_c_
//content of helper.c file
#endif
, which is kind of impractical and will always need inclusion of the .h and the .c file. But i only need to have them stored once, with no copies and if i need to change something, it will change in all projects, as they are all pointing to that folder
I also now about library files, where you have an .lib and a .dll file, where the .lib file needs to be pointed at by the library-path and the .dll file needs to be in the same folder as the .exe file afterwards. But that is not what i want.
My Question: Is there a possibility to store the .h and .c file (in my current case there are 10 file-pairs) in a separate folder and point at them via an include path or so? I tried googling around, but I think I am not quite sure what i shall look for.
Thanks for help
EDIT: I forgot to mention: I use Windows 7, and my current IDE is the LPCXpresso-IDE
OK, suppose you have this directory structure:
C:\users\documents\projects
|
+----- utility
| |
| +----- include (files not shown)
| +----- src
| |
| +----file1.c (and other files not shown)
|
+----- proj1
|
+----- include (files not shown)
+----- src
|
+----- proj_file1.c (and other files not shown)
And also assume, that the current directory for compilation is in the proj1/src directory. I see at least three solutions to your question:
if you really want to #include the source files, which I do not recommend doing, just use a relative path to the files i.e.
#include "..\..\utility\src\file1.c"
Now in addition to the issues with including source files, this tends to be very fragile in that if you change the directory structure (or change a name of a directory) everything breaks. You would need to go back into your source and fix every line of code.
As iharob suggested, use a make file to handle this. In this case, you would have a compile line that looked like this (assuming you are using Microsoft's tool change);
cl /I..\..\utility\include ..\..\utility\src\file1.c /o util_file1.o
This causes the result of the compilation to be dropped in the current working directory and the linker will be able to find all the object files and combine them together into one executable. We still are dealing with relative paths here, but all the changes would be in a single file, and by using make variables the changes would be on a single line or two.
If the functions in the utility directory are going to be used in multiple projects, my personal favorite solution is to make a utility project that produces a dynamic library (a dll under windows) and link subsequent projects with that library. You still have to deal with locating where the include files are going to be (maybe a directory at the top level of where all your project folders are?), but to me a library seems cleaner. It also has the added advantage that if you want to modify the code in the utility project, just recompile the library and the rest of you project will 'see' the modifications with out recompilation of them (assuming you do not modify the interface of the library).
Hope this helps,
T
Yes of course there is, depending on what compiler you are using there will be a switch to tell the compiler where to search for headers, for gcc and some others AFAIK, it's -I, so for example suppose that your headers are in the myproject/headers directory, the compiler should be invoked like this
gcc -I myproject/header ${OTHER_OPTIONS} ${SOURCE_OR_OBJECT_FILES} -o ${OUTPUT_FILE}
The usual way to build a project with the .c files in different directories is to use a Makefile and a program that can parse the Makefile and invoke the neecessary commands to build the project.
A word of warning: it is generally not a good idea to #include source (.c) files. The source files are meant for compilation, not inclusion -- including them may result in strange errors (most prominently, apparent re-definitions of a function).
Here is what I would do (for each project that needs the helper code):
Add your utility .c files to the project. Look for Add existing file... or a similar IDE feature; this ensures that your utility source files, i.e. helper.c, get compiled along with your project.
As for the .h file, include it with #include <helper.h>, enabling you to use your utility declarations.
Finally, find a compiler option called Include paths, a.k.a. -I, and set it to the folder that contains helper.h. This is usually found in Project options/settings.
After looking around through all the settings and options I found the following satisfying solution: creating a Link to a source file folder
This answer applies to the LPCXpresso IDE
imagine the folder structure shown in my question
inside the LPCXpresso IDE -> rightclick on the project -> properties
navigate to C/C++ General>Paths and Symbols>Source Loacation
click "Link Folder..."
in the opened dialog tag the checkbox Link to folder in the file system
click Browse... or enter C:\users\documents\projects\utility\src
click OK
click Apply
recompile and be happy :)
I have a C++ .h and .cpp file from another project that I want to include into my project.
I don't want to copy the files over into my project since I want any changes to those files be applied to both projects.
I've included the directory of the file's folder in the
Properties->VC++ Directories->Include Directories
I've also included the folder in the
Properties->C/C++ -> General -> Additional Include Directories
The .h files seem to work. If I rename the include to anything other than
#include "myfile.h"
The cpp file gets unknown definitions.
When I compile. The error is
fatal error C1083: Cannot open source file: '..\..\..\..\..\..\my project\myfile.cpp': No such file or directory
If I remove the cpp file from the project. Then I get a long list of unresolved functions.
error LNK2019: unresolved external symbol "public: unsigned long __thiscall myclass::myfunction"
How can I include both the .h and .cpp file into my second project?
For cpp files you can just use right mouse click on project, select "add"->existing item.
Then they should compile with others, when a build initiated.
Slightly more complicated with headers. There is two ways to use #include directive:
with < > and " " braces
When " " braces used, compiler treats path as relative (if not absolute used) to location of cpp file.
When < > braces used, compiler looks for file in something like system include folders. For example - stdlib headers folder and windows.h location folder. Properties entry Additional Include Directories also goes there.
I suggest you to change projects structure and extract shared features from both projects to compile it as static library. Place shared headers in some subfolder inside library project and refer then as
#include "mylibHeaderDir/someheader.h"
In dependent projects, after setting Additional Include Directories you can refer theese includes as
#include <myLibHeaderDir/someheader.h>
This approach will help you in future, as you can reuse that shared module in every project you want.
About how to create and link static library you can read this article http://msdn.microsoft.com/en-us/library/vstudio/ms235627(v=vs.110).aspx Version of visual studio may be differ, but basics are the same.
You can't just pick files like that. There are two reasonable ways to solve it. 1, shared the file by means of a Code Versioning System (e.g. svn/git). 2, compile the the .cpp into a library and link to that library.
If the cpp can be used by multiple projects, it must mean that the code is something common. That means you should compile that code by itself into a library and then share that library. Compiling the same cpp into multiple libraries is likely to result in conflicts later if two such libraries are ever needed to work together.
Try to drag them into your solution?
You can create a new folder in your solution, and drag them all into this folder!
I am having a problem of getting compile errors (red underlines) like:
Error: cannot open source file "stdafx.h"
Here an edited screenshot of the environment:
On the LEFT is my Visual Studio Solution Directory list with the "Show All Files" off.
I am working on a school project, and each Folder are the source files of different parts of the project with different people who are in-charge of them.
For example, Student A and B are incharge of AST and PARSER folders (we will call them sub-projects).
We have an API for each sub-project so other sub-projects know what to call.
At the TOP-CENTER, we have my Source File for a class QueryProcessor. (just the first few lines)
Below it, is the Output for the Build Success.
The red lines are all over all the classes, mainly cause the #include "stdafx.h" cannot be opened by the environment.
On the RIGHT, that is the stdafx.h where we include all the different sub-projects so we save the trouble of each project having a different stdafx.h
However, I am able to build the project. I am pretty sure I am doing this directory/linking wrongly.
This should work
Right click on the solution file
Click Open in Windows Explorer
Find file stdfx.h in explorer and copy the path of the folder
In visual studio solution explorer, Right click on the project file
Click properties-> C/C++ -> General
In the Additional Include Directories paste the path
Combining folders and virtual folders in VC is from my point of view messy because the virtual folders indicate that all files are in one directory and the folders created on the harddrive obviously indicate that all files are in different directories. You can combine it if you know what's going on but in your case I would not recommend it.
I assume you missunderstand the purpose of stdafx.h The purpose of this header file is NOT to put all header filles into it and then just include it to all other files. Here is a SO question about this Purpose of stdafx.h
After cleaning up your stdafx.h file include as many header files into your .cpp files and only put these includes in your header files if they are required in the header file
Turn on show all files, now you will work with actual folders and you can be sure that if you adress a folder like "PKB" that this folder really exists since you can see it in the left solution explorer.
If you use using namespace std; for example make sure you also include the required header files. You might think "hey I already included e.g. iostream in another header file which I now include in this header file so I don't need it" That will really destroy you when you work with bigger projects.
Oh and regarding the stdafx.h include problem as soon as you switch to show all files I assume you will realise that stdafx is in a different file than the file where you use the include. Maybe something like #include "..\stdafx.h" is required (depending on your structure).
I think it's obivious but if you include a header file the include is allway relative to the file which is including the other header file.
stdafx.h is commonly used for creating a precompiled-header, which essentially is a compile-time optimisation such that the compiler will not continually compile these headers for every compilation unit.
If any of these headers changes, you will need to do a full system rebuild.
In reality it is preferable only to use it to include standard headers plus third-party headers (like boost libraries and similar) that you are not ever going to change.
You may decide that some of your own libraries are "set in stone" and can also be included.
Every project, i.e. every part of the project that is built into a separate unit (DLL or .exe) should have its own precompiled header and its own version of stdafx.h
Projects should only ever include their own .stdafx and not those of other projects, therefore this header file can also be used to define your dllexport macro.
When arranging your project headers you should be aware of:
1. Which headers are included externally
2. Which headers are only included internally, and are not even included indirectly externally.
The latter sort should include your stdafx.h file and should ideally not be in the same directory as those headers included from outside your project.
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.