Lib depending on Lib, packaging for distro

[Christopher]

I tryed to make my hobby project look a little more like the projects
at work. In theory I could find the answer by examining the stuff at
work, but they use alot of custom build scripts and 3rd party
software, which I won't have at home. My goal was to create a single
library to be distributed to developers for use. So, I created a
directory "Redist", which in turn contains a "Lib" and "Include"
directory. My problem is that my entire solution consists of many
libraries, for example "Core", "Audio", "GFX", "Common", etc. For
anyone to use my lib they need the includes of course. But how do you
create one lib and include out of many? Especially when they are in
some complicated directory hierarchy during development?

Lets say Core is dependant on: Commo.lib, Audio.lib, and GFX.lib. The
output of Core is MyEngine.lib and MyEngine.h, which includes all the
Core includes...

MyEngine.h would also somehow have to contain a copy of the contents
for all the headers of its dependencies, no? Do I need some fancy
third party software to parse all my headers and generate a master or
something? Is there an easier solution?

These are all static libs btw. I wanted to do Audio and the others as
a static lib so I can re-use them in other projects.

 

[Jim Langston]

I tryed to make my hobby project look a little more like the projects
at work. In theory I could find the answer by examining the stuff at
work, but they use alot of custom build scripts and 3rd party
software, which I won't have at home. My goal was to create a single
library to be distributed to developers for use. So, I created a
directory "Redist", which in turn contains a "Lib" and "Include"
directory. My problem is that my entire solution consists of many
libraries, for example "Core", "Audio", "GFX", "Common", etc. For
anyone to use my lib they need the includes of course. But how do you
create one lib and include out of many? Especially when they are in
some complicated directory hierarchy during development?

Lets say Core is dependant on: Commo.lib, Audio.lib, and GFX.lib. The
output of Core is MyEngine.lib and MyEngine.h, which includes all the
Core includes...

MyEngine.h would also somehow have to contain a copy of the contents
for all the headers of its dependencies, no? Do I need some fancy
third party software to parse all my headers and generate a master or
something? Is there an easier solution?

These are all static libs btw. I wanted to do Audio and the others as
a static lib so I can re-use them in other projects.

Your header would only have to include the cotents of the headers that you
wanted to give the users direct access to. Your library would in effect
encapuslate the other libraries so that the end user should never need to
see or know about it's contents, including any headers. When your library
is compiled it uses the headers, but then gets compiled into a .lib with all
the information. The only thing you would need to include in your headers
is the calls to your library functions.

 

[Christopher]

Your header would only have to include the cotents of the headers that you
wanted to give the users direct access to. Your library would in effect
encapuslate the other libraries so that the end user should never need to
see or know about it's contents, including any headers. When your library
is compiled it uses the headers, but then gets compiled into a .lib with all
the information. The only thing you would need to include in your headers
is the calls to your library functions.- Hide quoted text -

- Show quoted text -

Yea, that is the problem. The end user, or rather the developer, will
need the headers from the other libs, such as the Logger class in the
Common.lib, or the Audio Manager from the Audio.lib. So, I guess I
will have to write some program or batch file that copies the contents
of all those headers into a header for the main lib, yicky.

Let's verify, before I do all this work. Simplified example:

Project: Common.lib
Users: EngineX.lib, and user of EngineX.lib
Contents: Logger.h and Logger.cpp

Project: EngineX.lib
Users: user of EngineX.lib
Contents: MyClass, which uses Logger

Procedure: Build Common.lib,
Copy Logger.h to EngineX/Redist/Include
Build EngineX.lib, linking to Common.lib
Copy EngineX.h to EngineX/Redist/Include
Copy EngineX.lib to EngineX/Redist/Lib

Now the user can link thier project to EngineX.lib, and include
EngineX.h and Logger.h where needed.
Alternatively, I can also write some program or batch file to get
all .h files in EngineX/Redist/Include and insert #include<filename>
in EngineX.h so they only have to include one file when using my lib.

Is that all correct?

 

[Jim Langston]

Yea, that is the problem. The end user, or rather the developer, will
need the headers from the other libs, such as the Logger class in the
Common.lib, or the Audio Manager from the Audio.lib. So, I guess I
will have to write some program or batch file that copies the contents
of all those headers into a header for the main lib, yicky.

Let's verify, before I do all this work. Simplified example:

Project: Common.lib
Users: EngineX.lib, and user of EngineX.lib
Contents: Logger.h and Logger.cpp

Project: EngineX.lib
Users: user of EngineX.lib
Contents: MyClass, which uses Logger

Procedure: Build Common.lib,
Copy Logger.h to EngineX/Redist/Include
Build EngineX.lib, linking to Common.lib
Copy EngineX.h to EngineX/Redist/Include
Copy EngineX.lib to EngineX/Redist/Lib

Now the user can link thier project to EngineX.lib, and include
EngineX.h and Logger.h where needed.
Alternatively, I can also write some program or batch file to get
all .h files in EngineX/Redist/Include and insert #include<filename>
in EngineX.h so they only have to include one file when using my lib.

Is that all correct?

Without knowing exactly what you are trying to achieve, it is hard to say.
If you are simply trying to take all the libraries that can be used by the
end user and link them into one library, for no other reason then they now
only have to link against one library, I don't think this is a good idea.
It sounds like you are not encapsulating the calls, but doing something
else. The best approach for an engine, IMO, is to encapsulate the calls to
other libraries.

This is veering off course for staying on topic for C++ (if it ever was). I
think you would get some very good answers in comp.programming as this
actually extends to more than C and C++ but libraries in general.

 

[Christopher]

Without knowing exactly what you are trying to achieve, it is hard to say.
If you are simply trying to take all the libraries that can be used by the
end user and link them into one library, for no other reason then they now
only have to link against one library, I don't think this is a good idea.
It sounds like you are not encapsulating the calls, but doing something
else. The best approach for an engine, IMO, is to encapsulate the calls to
other libraries.

This is veering off course for staying on topic for C++ (if it ever was). I
think you would get some very good answers in comp.programming as this
actually extends to more than C and C++ but libraries in general.- Hide quoted text -

- Show quoted text -

Agreed. Thanks.