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/)
Related
I decided to make a header file(s) that includes all the relatively simple methods I frequently use,to simply include said file into any project I'm working on instead of having to copy methods from one project to the other every-time I need them,I'm also going to be updating this file(s) as I go,now,I know there are multiple ways to go about including said file,either by adding it's file path to the #include directive itself,something like:
#include"C:\\Projects\\MyProgram\\Files\\MyHeader.h"
Or by adding the folder containing the header file(s) to the Additional Include Directories in the project's properties,which is what I'm currently doing,and it's working just fine.
However,I'm a bit worried about the fact the header file is not included INSIDE the project folder,so in the event I had to switch computers or wipe my hard drive,I'd have to make sure that this header file(s) is placed in the same exact file path,otherwise all of the projects that include it will simply fall apart...
And it goes without saying,I'm not making a copy of the header file to place in each project folder,for obvious reasons.
So I'd like to know if there anyway around this?
How about the ability to set an Additional Include Directory for ALL of my projects,so in the event of a wipe,a new PC or simply the old directory becoming inconvenient,all I have to do is set a new directory and all of my projects will start referring to that one?
If not,is my only choice is to build the header file(s) into a custom library? Because I know absolutely nothing about that,and I'd appreciate if someone would direct me to where I can learn to do that.
Thanks in advance.
You must use relative path. Do this:
1- Create a new subfolder in your solution. Let's call it include:
2- Put your shared headers in this subfolder. Example : myCommonFunctions.h
First solution: Use relative include path (see ../ at begining)
#include "../include/myCommonFunctions.h"
Second solution: Use relative path in Addtional include directories (see ../ at begining)
Now, you can write :
#include "myCommonFunctions.h"
By doing this, you don't depend from an absolute path C:\\Projects\\MyProgram\\... and You will no longer need to copy files manually if you change computers
As I am trying to learn C++ I have begun on a larger project where I try to use classes in order to avoid a messy main.cpp file. This means that I am creating more .cpp files which I have placed in the same folder as the main.cpp file. This has resulted in a messy directory aswell so I tried managing my files by adding folders following the two links:
Link1: https://hiltmon.com/blog/2013/07/03/a-simple-c-plus-plus-project-structure/
Link2: https://mariuszbartosik.com/directory-structure-for-a-c-project/
My questions are the following:
Does a standard for creating C++ projects exist that is used in a
workplace or is every project subjectively created?
If a standard does not exist are there any bad practises that should
be avoided when creating a folder structure?
Can I create a folder structure where I put all the header (.h)
files in one directory and all the source files (.cpp) in another
directory such as C:\headers\header.h and C:\source\main.cpp to
in my include use a #define HEADER "/path to header" and then
somehow #include HEADER "aheader.h" which would mean that I dont
need to everytime when including a header write the path to the
header directory and instead write HEADER before the include?
Example:
Instead of:
#include "c:\headers\header.h"
#include "c:\headers\anotherheader.h"
Use:
#define HEADER "c:\headers\"
#include HEADER "header.h"
#include HEADER "anotherheader.h"
I am asking this because I would like to avoid all bad practise when learning to code in C++ so I wont do mistakes later on. Since I have no work experience I dont know if the guides I found online are good ones in practise.
My current structure:
Does a standard for creating C++ projects exist that is used in a
workplace or is every project subjectively created?
No, you can find different structures across different projects.
If a standard does not exist are there any bad practices that should
be avoided when creating a folder structure?
You should:
Put your compiled files in a different folder (bin maybe).
Organize your project in different logical modules placed in different folders.
Use the root folder for not-code files (makefile, gitignore, etc...).
Use lowercase names only to avoid silly mistakes.
You should not:
Use absolute paths.
Can I create a folder structure where I put all the header (.h)
files in one directory and all the source files (.cpp) in another directory such as C:\headers\header.h and C:\source\main.cpp to in my include use a #define HEADER "/path to header" and then somehow #include HEADER "aheader.h" which would mean that I dont need to everytime when including a header write the path to the header directory and instead write HEADER before the include?
No, that's really bad.
I don't like use different folders for source/header files, but if you want to. You can work around using include paths (-l flag).
So you would use:
#include <header.h>
#include <anotherheader.h>
That works because you are including the folder on compile time:
g++ -l "../headers" enemy.cpp
Any sensible IDE will do this for you. Or you could do it on your makefile, whatever suits you.
Eigen is located in the file
C:\Users\jherb_000\Downloads\eigen-eigen-07105f7124f9
I thought to include eigen you just use
`#include "C:\Users\jherb_000\Downloads\eigen-eigen-07105f7124f9\Eigen/Dense" `
But it is not compiling. I know it can work because I have done it before, and the eigen website does not explain how to do this unless you are using specific programs like g++.
Since you imply via the tags that you're using qt-creator, your problem boils down to "How do I add an include directory in qt-creator?" There are answers for that here, here and others. One thing to note is that the path you should add is C:\Users\jherb_000\Downloads\eigen-eigen-07105f7124f9.
What happens is when you include a specific file in a specific directory, if that file doesn't #include any other files (ok, other files that aren't in the include paths) all works well. But if it does, (and Eigen files include other file in the Eigen project) then the compiler does not know where to search for them. That's why you have to explicitly tell the compiler which directories to look for files that are included.
Very easy. Let's say you have a dependencies directory, and inside you have the eigen directory. In your .pro file, you could add your dependencies path to your INCLUDEPATH:
INCLUDEPATH += ../dependencies/ # or wherever that path is (relative to your .pro file)
Then, to include the Dense module, you do:
#include <eigen/Dense>
where eigen refers to your folder eigen in your dependencies folder. Many variations possible in function of your setup, but you got the idea.
Ok then what you need to do is:
Copy the C:\Users\jherb_000\Downloads\eigen-eigen-07105f7124f9\Eigen directory and all it's contents to wherever you're keeping all your third-party library files on your machine. (You probably wouldn't want to keep these files in your Downloads folder). For example let's say this directory is copied to C:\jacks_code\Eigen. Then,
Add this new directory to Qt-creator's list of directories to search (see Aki's answer for links):
In each of your source files, to include the Eigen templates, use the preprocessor directive:
#include <Dense>
The compiler will use the directories you told it, to dereference the file to C:\jacks_code\Eigen\Dense (the complete filename). It's a bit confusing here because the files in the root Eigen folder don't have .h or .c or .cpp or .hpp extensions.
Hope that helps. You can also read the INSTALL file in the base of the unzipped package.
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.
In my place we have a big C++ code base and I think there's a problem how header files are used.
There're many Visual Studio project, but the problem is in concept and is not related to VS. Each project is a module, performing particular functionality. Each project/module is compiled to library or binary. Each project has a directory containing all source files - *.cpp and *.h. Some header files are API of the module (I mean the to the subset of header files declaring API of the created library), some are internal to it.
Now to the problem - when module A needs to work with module B, than A adds B's source directory to include search path. Therefore all B's module internal headers are seen by A at compilation time.
As a side effect, developer is not forced to concentrate what is the exact API of each module, which I consider a bad habit anyway.
I consider an options how it should be on the first place. I thought about creating in
each project a dedicated directory containing interface header files only. A client module wishing to use the module is permitted to include the interface directory only.
Is this approach ok? How the problem is solved in your place?
UPD On my previous place, the development was done on Linux with g++/gmake and we indeed used to install API header files to a common directory is some of answers propose. Now we have Windows (Visual Studio)/Linux (g++) project using cmake to generate project files. How I force the prebuild install of API header files in Visual Studio?
Thanks
Dmitry
It sounds like your on the right track. Many third party libraries do this same sort of thing. For example:
3rdParty/myLib/src/ -contains the headers and source files needed to compile the library
3rdParty/myLib/include/myLib/ - contains the headers needed for external applications to include
Some people/projects just put the headers to be included by external apps in /3rdParty/myLib/include, but adding the additional myLib directory can help to avoid name collisions.
Assuming your using the structure: 3rdParty/myLib/include/myLib/
In Makefile of external app:
---------------
INCLUDE =-I$(3RD_PARTY_PATH)/myLib/include
INCLUDE+=-I$(3RD_PARTY_PATH)/myLib2/include
...
...
In Source/Headers of the external app
#include "myLib/base.h"
#include "myLib/object.h"
#include "myLib2/base.h"
Wouldn't it be more intuitive to put the interface headers in the root of the project, and make a subfolder (call it 'internal' or 'helper' or something like that) for the non-API headers?
Where I work we have a delivery folder structure created at build time. Header files that define libraries are copied out to a include folder. We use custom build scripts that let the developer denote which header files should be exported.
Our build is then rooted at a substed drive this allows us to use absolute paths for include directories.
We also have a network based reference build that allows us to use a mapped drive for include and lib references.
UPDATE: Our reference build is a network share on our build server. We use a reference build script that sets up the build environment and maps(using net use) the named share on the build server(i.e. \BLD_SRV\REFERENCE_BUILD_SHARE). Then during a weekly build(or manually) we set the share(using net share) to point to the new build.
Our projects then a list of absolute paths for include and lib references.
For example:
subst'ed local build drive j:\
mapped drive to reference build: p:\
path to headers: root:\build\headers
path to libs: root:\build\release\lib
include path in project settings j:\build\headers; p:\build\headers
lib path in project settings j:\build\release\lib;p:\build\release\lib
This will take you local changes first, then if you have not made any local changes(or at least you haven't built them) it will use the headers and libs from you last build on the build server.
I've seen problems like this addressed by having a set of headers in module B that get copied over to the release directory along with the lib as part of the build process. Module A then only sees those headers and never has access to the internals of B. Usually I've only seen this in a large project that was released publicly.
For internal projects it just doesn't happen. What usually happens is that when they are small it doesn't matter. And when they grow up it's so messy to separate it out no one wants to do it.
Typically I just see an include directory that all the interface headers get piled into. It certainly makes it easy to include headers. People still have to think about which modules they're taking dependencies on when they specify the modules for the linker.
That said, I kinda like your approach better. You could even avoid adding these directories to the include path, so that people can tell what modules a source file depends on just by the relative paths in the #includes at the top.
Depending on how your project is laid out, this can be problematic when including them from headers, though, since the relative path to a header is from the .cpp file, not from the .h file, so the .h file doesn't necessarily know where its .cpp files are.
If your projects have a flat hierarchy, however, this will work. Say you have
base\foo\foo.cpp
base\bar\bar.cpp
base\baz\baz.cpp
base\baz\inc\baz.h
Now any header file can include
#include "..\baz\inc\baz.h
and it will work since all the cpp files are one level deeper than base.
In a group I had been working, everything public was kept in a module-specific folder, while private stuff (private header, cpp file etc.) were kept in an _imp folder within this:
base\foo\foo.h
base\foo\_imp\foo_private.h
base\foo\_imp\foo.cpp
This way you could just grab around within your projects folder structure and get the header you want. You could grep for #include directives containing _imp and have a good look at them. You could also grab the whole folder, copy it somewhere, and delete all _imp sub folders, knowing you'd have everything ready to release an API.
Within projects headers where usually included as
#include "foo/foo.h"
However, if the project had to use some API, then API headers would be copied/installed by the API's build wherever they were supposed to go on that platform by the build system and then be installed as system headers:
#include <foo/foo.h>