- Forum
- General C++ Programming
- Static library
Static library
Hello, I am having a problem where I have two projects in Visual Studio, one is a static library (.lib) and the other is and executable (.exe). The executable project is has a reference to the lib project. Also in the compiler include path of the executable, there are the lib project's source files. Now the problem is that in the compiler include path of the lib project, there are other include paths that the executable knows nothing about. Let's say there is a file in the lib project:
//files.h
#include <GL/glew.h> //compiler include header file.
Now this is my executable project, one of its files:
//game.h
#include <files.h>
Now when I build the library project, it works with no warnings or errors. But when I build the executable, it gives me the error : "Cannot find include path "GL/glew.h". Note that this error is in game.h, NOT in files.h.
What is the solution to this? I want the executable to NOT access "glew.h" but do access "files.h"...
//files.h
#include <GL/glew.h> //compiler include header file.
Now this is my executable project, one of its files:
//game.h
#include <files.h>
Now when I build the library project, it works with no warnings or errors. But when I build the executable, it gives me the error : "Cannot find include path "GL/glew.h". Note that this error is in game.h, NOT in files.h.
What is the solution to this? I want the executable to NOT access "glew.h" but do access "files.h"...
Last edited on
does gl/glew happen to be included inside files.h?
It looks like it is from what you posted but I want to be very clear here.
If it is, then if you include files.h you also MUST have gl/glew available. Its chain included.
If the library has all the graphics inside it, then files.h should not need gl/glew in it; that won't be exposed to the calling program.
basically your library project may need to move the gl headers out of the wrapper/library exposed header and keep them 'local' to its inner workings.
libraries typically have ONE header file that has ONLY what the library user's will see, and nothing else. They have other header files with things the caller does not see, but the interface header file needs to have the least amount of stuff to use the library.
It looks like it is from what you posted but I want to be very clear here.
If it is, then if you include files.h you also MUST have gl/glew available. Its chain included.
If the library has all the graphics inside it, then files.h should not need gl/glew in it; that won't be exposed to the calling program.
basically your library project may need to move the gl headers out of the wrapper/library exposed header and keep them 'local' to its inner workings.
libraries typically have ONE header file that has ONLY what the library user's will see, and nothing else. They have other header files with things the caller does not see, but the interface header file needs to have the least amount of stuff to use the library.
Last edited on
If your executable source code contains
If you don't want your executable build to have to see
#include <files.h> , then EVERYTHING that is #include d in file.h must also be visible.If you don't want your executable build to have to see
#include <GL/glew.h> , do not put #include <GL/glew.h> in any file that is compiled when the executable is built. You can do this by moving #include <GL/glew.h> out of files.h
Last edited on
Lol, that is exactly what I don't want to do... Thanks anyway :)
I solved it by adding the same include paths for both projects.
I solved it by adding the same include paths for both projects.
But you said
The executable (or rather, the buiding of it) is accessing
| I want the executable to NOT access "glew.h" |
The executable (or rather, the buiding of it) is accessing
glew.h; you said you didn't want that.
Last edited on
copy just the #includes and function protos in file.h to another file, lib.h or whatever. Delete things you don't need. Use that for the user of the library.
Topic archived. No new replies allowed.