TIGSource Forums

Hello there.

This is a question that has kept me wondering for way too long, so now is the time to ask you, and hopefully you have an answer for me.
I've been thinking... Say I create a C++ library for graphics, using SDL for the window.
How would I handle not having to force the user to get SDL separately? You know, so smoothly that the user wouldn't even have to know I've used SDL?
Would I pre-compile it somehow? Would I create a makefile of my own, that first compiled SDL and then my library?

I haven't done this, but I think I will in the future, and if I were to ship this library to somebody else than myself, I wouldn't want it to be hard for them.

Let's also throw OpenGL into the mix. OpenGL 3.1+. How would I deal with it, since it's not standard? Write a script that checks for the existence of the GL3 folder, and if it doesn't exist, create it, and put gl3.h, which I shipped with my archive, into it?

Basically you have two options.

1. Link with SDL statically. Because of the LGPL license, this means you have to make your library open source as well. Besides, if you choose this route, the user of your library could be in for a world of pain if they choose to use SDL too, for other functionality, so you should be very sure that that will never be the case or is not problematic.

2. Link with SDL dynamically, i.e., include the SDL DLL with the distribution of your library. In that case, I guess it's easiest if your library is a DLL as well, though statically linking might work...

I'm not sure how to do this.

I wouldn't make a library specifically for Windows.
I would probably develop it on Linux or Mac, and I would make sure it would be portable for all three.

Binaries are more-or-less always platform dependent. Shared objects are the equiv of dlls.

Static linking is not too difficulty, depending on your compiler. I suggest you read up a bit on what linking means before you attempt it (hint: the wikipedia articles on this are shit), but if you state your setup, we can offer mild help from the sidelines.

Also, I don't think you can avoid making users have openGL installed - it's not a regular library as I understand it, as it actually interfaces with hardware. The .h is just what YOU need to compile your code against it, there's obviously a great deal there needed in the distribution.

I don't know if you're speaking hypothetically about your library, or if you are actually planning something that'll work with SDL and OpenGL 3.1, so I'm going to assume that's what you're actually planning.

As far as I can tell, the "norm" for building stuff on top of SDL is just to be honest and tell people that's what you're doing. If you go to the SDL site you can see plenty of libraries people have built specifically to sit on top of SDL and extend its functionality in certain ways. As I see it, this is a Good Thing - if someone is using SDL and thinks they might want to use your library on top of it, they will; if someone really wants to use your library and isn't using SDL, they can start using it alongside your library; and you don't have to work out how to have your library support anything else.

OpenGL 3.1 is trickier - I've not seen any libraries that require bleeding-edge versions of OpenGL before, and I'm not sure what sort of library (other than some kind of super-advanced experimental rendering engine) would require it. Obviously if people really want to work on stuff that new then they'll have installed the necessary stuff to run 3.1 anyway. Most stuff I've seen that's OpenGL based and nontrivial tends to have ways to perform differently depending on what features are available, either with compile switches or with runtime checks, so that's a friendlier way of doing it.

Thanks for the replies.

I do know what linking is; I compile stuff just about every day.
What I do not know, though, is the difference between static and dynamic linkage, and I will definitely look their definitions up. Thank you.

As for the .dll and .so files; I am well aware of the fact that Windows use one of them and Linux use the other.
I just felt like it was assumed that I didn't want to make the library available for anything else than Windows.

Yes. Yes. Of course SDL is a great library (I obviously wouldn't use it if I didn't think so), and the authors deserve all the credit in the world for making it, which is something I would most definitely do what I can to grant them.
What I meant by expressing myself in such a way, saying that the user wouldn't even have to know that I've been using SDL, was that it shouldn't be more work than necessary for the user to install the library; (s)he should be able to just run the installation for the library and then get going.

I know that the modern OpenGL support is also an issue of hardware and drivers, but still, having OpenGL 3.2 support doesn't necessarily mean that you have the development header installed, or that it is installed in the correct location. Having the support would obviously be a prerequisity, since there would be nothing I could do about that, but having the development header shouldn't be.

That wasn't the intention. I meant DLL generically (though from an admittedly Windows-biased view) as a shared library, whether it is a .dll or .so or whatever it is on OS X. While the implementations differ between the platforms, the basic concepts of dynamic and static linking are the same.

An important thing which you haven't mentioned yet is whether you plan to release source. This might change your distribution strategy, as on Linux the easiest thing is generally to let the user compile.

By the way, this is off-topic and strictly out of curiosity: why do you want to require OpenGL 3.1 or even higher? It seems that would exclude a large portion of the indie developer and player base who don't keep their machines at the bleeding edge...

Actually, 3.1 is supported by hardware as far back as ATI HD2000 series and NVidia 8 series cards.  Believe it or not, those cards are approaching 4 years old.  I would not consider those "bleeding edge".

This is a dependency problem like any other, the fact that it's a library rather than an application makes no effective difference, you just don't have an application entry point.

It's not uncommon for libraries to have dependencies on other libraries, especially those that somehow wrap others.  My OpenAL interface for Ada for requires OpenAL, Freetype requires zlib, etc...

Your best bet is to simply list the dependencies.  Static linking is a bad solution, I believe, for a few reasons.  One, your binary is going to be huge, or at least bigger than necessary.  For libraries this is kind of a big deal.  Two, as someone already mentioned, if the user is also using SDL, you may run into nasty version differences, including link failures due to name clashes.

Developers should know enough to understand library dependencies and how to deal with them, and if they don't, you can write a FAQ or something.  Documentation is the best solution.

Yes, I would release the source.
I want to use 3.1+ to follow the new standard.

@Average Software:
I guess you have a point. People using the library to a greater extent would be programmers who know how to install a library.
Still, though, I would like there to be as little work as possible to do so.
Are there not other options, such as installing SDL in a non-standard location, renaming files, running them through some kind of obfuscator, or simply telling the user that it will overridde any version of SDL installed in a standard location?

My main desktop PC has a Radeon 9500. My laptop is a Dell with an Intel graphics chipset which doesn't even handle multisampling. Need I say more? ;) A 3 years old graphics card is quite recent by my standards. Still, I can play most if not all of the games which are posted on TIGSource without problems. Indies aren't tech-heavy typically. I think it's foolish to "follow the new standard" for the sake of it if the game doesn't make use of the new features. Anyway, as far as I recall OpenGL was seen as a huge disappointment in the game development community since it mainly pandered to the needs of the CAD crowd.

Fine, then Linux should already be no problem: just tell people to install the development packages for SDL and let them compile from source. I have no experience with Mac OS X, but I would hope that it should be similarly simple? And for Windows, provide your library as a DLL and include the SDL .dll with the binary distribution.

Installing it isn't really the issue... once you link statically, the library becomes a part of the program. I guess you could play some foul tricks with the preprocessor to give the statically linked version of SDL some unique prefix in order to avoid clashes, but really, that's all very hackish. The nicest solution should be dynamic linking, by and large. Go ahead and read up on the distinction between static and dynamic linking, it should clear some things up.

Being UNIX based, installing a library on Mac OS X is generally exactly the same procedure as in Linux.
But... damn. I don't want to have to change bunches and bunches of little details for every function and file to turn it into a DLL for an operating system that is of my least concern; if I write portable code from the beginning, I want it to be, well, portable. Surely I don't need to make any DLL or Shared Object files?

Libraries on OS X are generally a bit more than just a binary.

They're usually distributed as frameworks, which are actually directories.  The framework contains not just the binary that you link to, but all the headers necessary to use the library.  It's an all-in-one type deal, very similar to OS X application packages.

You don't need to make binaries, in fact, you might be better off not doing so.  Just providing the source is a perfectly valid option, and hundreds of libraries do this.  If the developer wants to make a binary for their own purposes, they can do so.  My one library (the Ada OpenAL interface) is just a source distribution, this neatly avoids almost all of your problems.  When you do binaries, you run into issues with architectural differences (I know lots of people who run PowerPC Linux distros, your x86 binaries are useless there) 32/64 bit issues, and who the hell knows what else.

Another approach is to make binaries for a few systems, and make the source available for anyone that wants to make them on their own for "unsupported" systems.

Addendum:
I would also like to add that if you're using C++, binaries may not even be an option.  Differences between compilers in areas like name mangling and object layout will not just tie your binary to the compiler it was built with, but maybe even the specific version of the compiler it was built with.

Talk about an oxymoron! ;)

In all seriousness though, you're right regarding the Intel chipsets.  Intel is probably the worst thing to have ever happened to the graphics chipset world.  And I'm certainly not the first to have ever voiced that opinion.

At the end of the day like you said, you need to asses and identify the features you need/want in order to execute your vision and make an API judgment call based off that assessment.

But that's not really the primary topic of this thread, so I'll stop now. :)

Yeah, that's a nasty point. One way around it is to write the library in C++, but provide a C interface to it.  The ODE physics library does it like this, for instance.  As a nice side effect, this makes it very easy to create bindings to other languages.  My Cosyne library, which is written in D, uses the same approach.  Of course it depends on whether the design of your library allows it; if it's heavily inheritance-based or templated, this is probably too much trouble.

Who is the "user" here, to you? Is it the person who will be using your library as part of a bigger project (i.e. a programmer), or the end-user, the person who just wants to install and play a game? If you're writing a library, your user has got to be a programmer. The end-user is your user's problem, not yours. So. Programmers are not stupid. If they know enough to want to use your library, they should know how to incorporate it into their project, along with any dependencies your library has (SDL, etc). Even more than that, if you try to "hide" what libraries your library is based on, and magically install it for them, they'll hate you for it. Programming is about control, and about access to knowledge. Tell people what your library is based on, provide documentation that tells them how you think it's best to have those dependencies set up to run well with your library, but leave them to work the rest out.

When I'm evaluating a library, there are a few things that are important to me, and none of them involve whether the installation process can magically set up SDL for me. I don't want that. What I want is:

• Open-source with a reasonable license. If the license is LGPL, I'll settle for a DLL and a header file so long as they work, because I don't want to statically-link and have to open-source my whole game.
• A tight, focussed idea about what the library is for
• A small library, with the minimum number of dependencies required for it to work. I'll take something that does a job in a half-dozen source files over some 300 file monster with a pile of obscure dependencies anyday.
• An easy way to extend or tweak the library if I want to.
• Good documentation, and an active forum where I can go for help.

I mean the programmer.

Of course they're not stupid. I just want it to be very quick to set up, and I do not, in any way, want to hide the fact that it's using SDL; I just want it to be very quick and easy to set up.

I wouldn't even require credit, even though I would of course appreciate it. I give credit to the libraries I use in my programs.

I would provide many things. Tutorials would probably not appear right away, but I use Doxygen, and I would of course write a description.

A half-dozen? Six files? That's three classes.
No, my library would not have three classes.

That's why I would want the source open.

Like I said, I use Doxygen.

Heh, it depends on the library, obviously :) My point was that I personally prefer small, tight libaries that server a well-defined purpose and do it with the minimum of fuss, rather than big sprawling all-singing all-dancing affairs. Other programmers views may vary - for instance, CEGui seems to be a popular GUI library with a lot of people, but it was just too huge and unwieldy for what I wanted, so I went with Guichan because it's much more compact (although the support for it is crap - they closed down their forums because of spammers).

It sounds like we're broadly in agreement on what makes for a good library. I just got a bit confused because it sounded like you wanted to build on these things in a way that provides some kind of auto-installer for SDL. I suppose the cleanest way to do it would be to not include any kind of SDL stuff as part of your library package, but to write it in such a way that it sits cleanly on top of a fresh setup of SDL, so that if programmers have done something unusual with their SDL setup, the onus is on them to configure your library to conform to that, but if they're trying to run it "out of the box" they can just start a fresh SDL project, add your stuff in, and be ready to go.