In a typical C++ application (no Qt), I may have the following:
app/include/namespace1/Foo.h
app/src/namespace1/Foo.cpp
app/include/namespace2/Foo.h
app/src/namespace2/Foo.cpp
Where "app" is the root folder for the project. The classes in those files are:
//In app/include/namespace1/Foo.h
namespace namespace1 {
class Foo;
}
//In app/include/namespace2/Foo.h
namespace namespace2 {
class Foo;
}
In a build system like the one eclipse has, the object files for each .cpp files will be built into diffrent subdirectories.
In Qt, I create a .pri file in each of my folders which contains include, SOURCES, and HEADERS statements. However, when Qt builds the program, it places all of the object files in the same directory. So, [build output]/Foo.o gets generated twice and thus overwritten causing the linker to fail.
I looked into making each nested folder into its own SUBDIRS project with its own .pro file, but this doesn't work correctly since each folder is not an independent project, just an independent namespace.
What is the correct way to setup a project like this?
Here is one answer: https://riptutorial.com/qt/example/15975/preserving-source-directory-structure-in-a-build--undocumented---object-parallel-to-source--option--
This causes Qt to generate a directory structure in the build directory that "mirrors" the source directories.
Related
I am refactoring a code project (written in both c++ and c#) in visual studio and the structure of my directory is roughly like the attached picture here : enter image description here
P.s project2.sln is a part of a big project in the same directory.
Inside the commonFolder there are some .h and .cpp files that are used by the project2.sln located in folder 2.
I want to move this commonFolder to the SharedFolder and instead of giving an absolute path, I would like to give relative path (using Macros) to the properties of project2.sln so it can be compiled for all the users that checkout this trunk folder.
How can i define this relative path for the commonFolder using Macros?
Additional Include Directory is the convenient way to give relative path.
As an alternative, you can use shared item project.
These “shared items” projects don’t participate in build but they can
contain any number of C++ headers and sources.
move .h and .cpp files to shared item project folder.
add existing item in shared item project
add references in the project2
find the places where the error: cannot open the file. Modify path:
For example: #include "E:XXX/folder2/commonFolder/test.h" to #include "test.h"
I'm trying to build a Makefile with separate folder for my sources and my headers. I have a the root of my project that contain an include folder that holds my .hpp files, and a source folder that holds my .cpp files. How can i build the Makefile that it builds all the .cpp with the respective .hpp files ?
How to create the program output in a folder called build ?
Thank you in advance
Make is so diverse, there's a LOT of ways to do this, but the end result is -I<your hpp path> (or -J) needs to be passed to the compiler to tell it additional include paths to search when resolving #include
The path needs to relative to the invocation of the rule directory, or relative to the file (I'm pretty sure the compiler searches both).
A lot of makefiles use CPPOPTS and CCOPTS or some variant of that in the makefile to pass extra options to the C or CPP compiler. Try adding:
CPPOPTS += -I..\include
To your makefile (assuming you've segregated your source and include files that way).
Again, this is ALL dependent on your makefile.
I'm trying to build a Makefile with separate folder for my sources and my headers.
An alternative way would be to have your headers in the same directory as your .cpp files. And in that top level include folder you can put symbolic links to the headers.
I am developing a product with a team using CMake. We have several Visual Studio projects (libraries and executables) inside of our CMake project which reference other project headers (via target_include_directories()). In a source file these header includes look like:
#include "some_header.h" // from project_x
#include "another_header.h" // from project_y
I'd like to be able to include these headers with paths that reference the project they are pulled from, e.g.:
#include "project_x/some_header.h"
#include "project_y/another_header.h"
What is the most acceptable way to do this? I have thought of a couple solutions:
Add the directory which contains the project as an include path. This has the undesirable side-effect of including everything and seems like a bad solution.
Include a subfolder of the project called 'include' which contains a folder named with the same as the project, which creates a slightly redundant path: /<project_name>/include/<project_name>/<...>
There is a third solution, to use a shared include directory with a subfolder for each project, but it will not work for our project because we group our build projects by category in the file system and Visual Studio solution and it will cause the folder structure inside of /include/ to diverge from the rest of source tree which is undesirable.
Are there any better (or more canonical/idiomatic) ways to accomplish this?
If you have a project structure like this:
project_x/some_header.h
project_y/another_header.h
and you want to keep all of your CMakeLists the same, then I would introduce another folder in each project:
project_x/project_x/some_header.h
project_y/project_y/another_header.h
Of course, this requires changing the includes in each project to reflect this new structure, including the project where the header is defined proper.
There's some precedence to this, as this is how curl and googletest do it.
Edit: I understand this is very similar to the second approach you outlined. If your directory structure already employs include directories, then my suggestion is exactly the same as your second one. At the very least, this should confirm your intuition that this isn't an entirely absurd thing to do, even if it creates some redundancy.
I created a class (say, myclass.h/cpp). I want to use the class from many different places. Therefore, I put those files in a folder (say, C:\cpp_include) and I want to include them from whatever folder my codes are. I have a code which uses the class (say, main.cpp). In main.cpp, I include myclass:
#include "myclass.h"
I compile using a .pro file and nmake. In the .pro file, I specify the folder as:
INCLUDEPATH += C:\cpp_include
When I compile the code using nmake, myclass.h is properly included, but myclass.cpp doesn't seem to be found by compiler.
When I specify myclass.cpp as one of the source files in .pro file:
SOURCES += main.cpp C:\cpp_include\myclass.cpp
The exe file is built correctly. But, I would like myclass.cpp file to be found automatically when myclass.h is included, i.e. without setting myclass.cpp as a source file. Would this be possible? It looks like that's what happens with classes from Qt and Qwt (e.g .h/cpp files in /src/ folder in Qt and Qwt). Am I missing somthing?
Thanks a lot!
Daisuke
A simple technique is to have build scripts (makefiles) in the cpp directories. Write a rule that traverses the directories, executing the build scripts. This one step in isolating functionality and also allows one to use libraries.
That's just not how it works. The .cpp is the file that matters, header files (.h) just get copied into the other .cpp files. Therefore you need to add the myclass.cpp to your sources for compiling. Or, if it's a library class, you could also compile it once into a static library (.lib) and just add that to your linker files. But you ultimately need to somehow include you implementation in the project where it's used.
Here is my folder structure:
/
|
-- program.cpp
-- utility.h
-- utility.cpp
|
-- module/
|
-- utility.h
-- utility.cpp
// Note that I have two files named utility.h and two named utility.cpp
On building the project, I get a link error (LNK2028: unresolved token and so on...) saying that some symbols aren't defined. I have confirmed that all symbols are defined and that all declared functions have a corresponding definition.
I have a feeling that on compiling my project, the utility.cpp files from both folders are compiled into the same utility.obj in the output folder. As a result, one overwrites the other.
Is this expected behaviour?
How do I
build a C++ binary which has two
files with the same name (though in
different folders)?
Right click both/either .cpp files > properties > C/C++ > Output Files > Object File Name > set a custom name. e.g. if both files are named MyFile.cpp in folder A and another in folder B, you can set the output to be AMyFile and BMyFile.
Alternatively, you can also use a macro to prefix the object names with the immediate parent folder name (i.e. using $(IntDir)\$(SafeParentName)$(SafeInputName)). If this is not enough (e.g. you have A/B/MyFile.cpp and C/B/MyFile.cpp) and you don't mind having some object files cluttering your source tree, you can also use $(InputDir)\ which will put the object files in the same folder as the source file.
the cpp files will then be compiled into two different object files..
enjoy!
Update for VS2010: There is a better solution in VS2010, check it out here. Thanks to n1ck's comment
btw, if the contents have the same name, do you separate them using different namespaces?
namespace A { // in folder A
class CMyFile {};
};
namespace B{ // in folder B
class CMyFile {};
};
// client.cpp
#include "A/MyFile.h"
#include "B/MyFile.h"
int main() {
A::CMyFile aMyFile;
B::CMyFile bMyFile;
return 0;
}
I don't know if it matters but it's definitely clearer to human : D
You could try adding another project to your solution, which will build a static mudule.lib file from your module's .cpp .h, then link your main project with that lib. It should make VS to output .obj files in a separate directory, and you should be able to link without problems.
Do you really WANT two different but same-named files in the same project?
The easiest thing that works well is put the conflicting .objs into different subfolders (I've used this technique with 2003 and 2008) based on the source dirs.
For example:
For src\gui\utils.cpp set "Object File Name" to ".\Debug\gui/" and
for src\database\utils.cpp set it to ".\Debug\database/".
While I do it manually whenever I spot a conflict, I can imagine that writing a script that updates the project for every .cpp file (or just for conflicting ones) would be a pretty trivial task.
Maybe libraries (static or dynamic) would help with your case. But you will still have problem if there are any public symbols with the same name like in executable or other library.
I don't know the VS compiling chain.
However, each .cpp is first compiled into a .obj file. The linking steps merges them together.
It's very common, to put all the .obj files in a same directory. So, as you guessed, when compiling the second one, erases the first one. Therefor some symbols are missing during compilation.
There probably is an option (again, I don't work with VS) to leave the .obj in the same directory as the .cpp file. The drawback is some garbage on your source code tree.
My personnal opinion would be to refactor.