Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML-like library system  (Read 2785 times)

0 Members and 1 Guest are viewing this topic.

Beta_Ravener

  • Jr. Member
  • **
  • Posts: 51
    • ICQ Messenger - 271426715
    • View Profile
SFML-like library system
« on: January 17, 2012, 08:06:58 pm »
Hello.. this is quite a bit off-topic, but still SFML related so I'll give it a try.
I'm building my own library to concentrate many source files and headers that I'm now just copying between projects and compiling them over and over again, getting lost in where is the last modified version etc. I haven't previous experience with doing so, therefore I've chose to copy someone's else. Well and as I'm big fan of SFML and pretty impressed of how that word Simple fits in there, I tried to copy this one. I was particularly successful in creating similar file system and compiling library. However, I encountered few problems that I'd like to ask about, because SFML doesn't have such. For now I'm compiling my library with Visual Studio 10 and I don't have CMake solution yet, only visual studio project.

- GLEW include path needs to be specified in project using my library
This is biggest catch. When starting a project that should use my library, I include main include file (something like SFML/window.hpp). That file includes glew.h, thus the project that want to use just my library needs to know also about GLEW. I've noticed you're solving this by creating GLcheck.hpp and including it only to .cpp files. This way the user project doesn't have to know about glew. However, I'm using some GL data types defines (GLint) in declarations in headers, therefore I need to have GLEW included also in header. Is there any other work-arround than changing those to native data types?

- Static library size
My library is much smaller than SFML (number of lines, files, etc.), but still size of the resulting static library is greater than all SFML libraries together. I tried to play with project setting so I would get the same as SFML have, but it didn't do big difference. I think there might be problem connected with previous paragraph. If whole GLEW would be linked to static library, it could create such big libraries. (Note that my testing libraries don't exhibit such problem)

- Building both dll and lib whit single configuration(Release, Debug, ..)
I'm pretty interested in how is this possible, because I can only make configuration that produce static library or dynamic (project properties-> configuration properties-> general, configuration type [options: makefile, exe, dll, lib, utility]). This way I need to create one configuration for compiling static(lib) and one for dynamic(dll) library. SFML visual studio project created with Cmake produce both in single configuration e.g Release. Do I have to use Cmake for such option?

I don't know how much you (or people willing to input something to this topic) are familiar with visual studio, I just want to test everything out and solve major problems before getting my hands on Cmake. Anyway, I believe that you're more than competent to answer my questions as similar problems must have been addressed when creating SFML(or any other library). Also if you had some very good source where you learned something about building more advanced libraries (not just sample ones), I'd be more than interested in those.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML-like library system
« Reply #1 on: January 17, 2012, 10:45:43 pm »
Quote
Is there any other work-arround than changing those to native data types?

Unfortunately not.
In fact there is one, but it can be quite heavy and not good for every class, it's the pimpl idiom. I let you discover more about this technique with Google.

Quote
- Building both dll and lib whit single configuration(Release, Debug, ..)

It is impossible to create two different builds with a single configuration. You must have misunderstood something. The DLL build produces both .dll and .lib files, but the latter are just import libraries (the bridge between the application and the DLL), they are not static libraries at all. If you thought they were, this may explain your second problem as well ;)
Laurent Gomila - SFML developer

Beta_Ravener

  • Jr. Member
  • **
  • Posts: 51
    • ICQ Messenger - 271426715
    • View Profile
SFML-like library system
« Reply #2 on: January 17, 2012, 11:49:32 pm »
Many thanks for reply.

I've heard about pimpl idiom before, in fact I had to use such things in one of my projects, but they're really messy. I've inspected the glew.h to get some details about GL types, and it seems they won't be changed any time soon (they're in section GL_VERSION_1_1), and only difference for native data types comes with 64bit integers that I don't use. But it was good way to confirm my assumption.

The later is more interesting information. It helped me with a dilema I was facing - why would dynamic libraries exist if we had to create also static ones every time :D I'm going to search something about import libraries, but I feel you saved me from days of frustration :)

 

anything