I am working with the OpenSSL library for C++. I used this library in another project and it worked great. I carried it over to another project today and I'm having issues.
Two of the header files are .h.in files: opensslv.h.in and configuration.h.in.
In the first project, this was not an issue. But in my new project it gives me an error on this line
#include <openssl/configuration.h>
because configuration.h cannot be found:
...\include\openssl\opensslconf.h(14): fatal error C1083: Cannot open include file: 'openssl/configuration.h': No such file or directory
I understand there is no literal configuration.h file but from what I understand that configuration.h.in file should generate a configuration.h file right?
Does anybody have any idea why that might be happening? Maybe I changed something in the project properties?
.h.in is a template for a header file.
.in suffix looks similar to autotools template files, but according to their FAQ, OpenSSL uses their own build system based on Perl.
Anyway, you should call one of the Configure scripts, and build after that. Docs.
I'm unable to comment, but you need to provide more information about your directory structure. What do you mean by "carried it over"? This most likely sounds like it's happening due to something pointing to the wrong directory. What environment are you working in?
First thing I would do is double check that your project environment is looking in the correct directory for include files.
I also just found this answer that may be helpful to you as well: https://stackoverflow.com/a/31322172/2494727
I'm trying to create a new project with lpc11u68 MCU for USB HID application based on the LPCOPEN sample project.
The problem is, the compiler can't recognize header files on the other folder. It shows this
error:../Main/src/Main.cpp:12:26: fatal error: app_usbd_cfg.h: No such file or directory
I've exactly done all of the instructions in this tutorial but the problem is still alive. When I copy all header and sources to the main directory of the project, it compiled correctly!
I was using quick setting -> include path for introducing my header's path to the Xpresso. This acts just as the instruction described in above tutorial, but only in C projects!
When you used that shortcut in C++ project, it adds paths to the C compiler Includes not to the C++ one! What an interesting bug!
I want to build a little project that utilizes the QR Encoder. I simply used Cocoapods to install it within my project and included the QREncoder.h file within my bridging-header, which works just fine for a couple of other Objective-C resources. My problem occurs because I am including the QREncoder.h file which the includes the QR_Encode.h file. This file uses a pretty standard C++ class definition class CQR_Encode{...};, but when I'm trying to compile my code now, I get the following error /PATH_GOES_HERE/Pods/QR-Code-Encoder-for-Objective-C/QRCodeEncoderObjectiveCAtGithub/QR_Encode.h:81:1: Unknown type name 'class'; did you mean 'Class'?. Looking for that error on the internet got me the information, that I need a Objective-C wrapper class for that file, but I thing QREncoder{.h,.mm} should do the job. I also changed file type within the attributes inspector to either 'objective-c++ source' or 'c++ header' but that did not change the error. I also tried setting the 'compile sources as'-setting in build settings, but of course this didn't work since it sets the compile type for all files and since there are Objective-C classes, it won't work. Does anyone have an answer to help me out?
The src file is broken down into different libraries and inside each one is the xxx.c and its xxx.h counterpart. In almost all of my classes I get file not found errors on the first import statement for the .h file. I deleted the "library/" and it removes the error. I was wondering if there is an easier way to to this other than going through each of the 1000 classes and doing this for each of the import statements. I have already included sdl framework in the "Link binaries with Libraries". Please help im lost.
Try using the USER_HEADER_SEARCH_PATHS for paths you want searched for #include "..." You can find this option in Build Settings of Target.
You can specify path like this: $(SRCROOT)/Subfolder/subfolder
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>