[C++]Using an API
Author
I've been fiddling around w/ vaious APIs like SDL and MySQL, and I'm wondering, what is the best way to manage the installations of all these APIs? Usually I'd just take the libs and includes and merge them into my MSVC++ .NET VC7 folder and it works just fine, but is that 'sanitary'? I'm sure there's probably a better way because once I toss all those APIs in there, there might be files w/ the same names and want to overwrite each other and such and mess it all up. Thanks!
You could just put them into their own subfolders. You'll have to type the path from your include folder in the #includes. for example put all of sdl into its own folder called SDL (it usually can be extracted out of the zip file this way) and use #include <SDL/sdl.h>
I find dealing with installing API's is only a perference to whom ever installs them. Personally I keep all my API's in the c drive by with directory names (lua, SDL, ect). Maybe thats even more insanity? I guess you could organize them if you wanted to but I see no real reason as long as it works.
Yes, I myself like things rather neat and tidy on my computer however my problem was more having to link everything I needed to start a new program using a particular API. It can be very discouraging. So I tried to look up custom wizards such as Win32 Project and Console Project but had no luck and soon got lost. Ah well I guess everything in life can't be general AND simplified. If you were really worried about where your API's are installed to I would just suggest chucking them all in there own folder such that you have
C:\API\DX or C:\API\SDL
C:\API\DX or C:\API\SDL
My approach is somewhat involved. On my computer I created three extra directories on the C drive: C:\bin, C:\include and C:\lib. An abbreviated look at these directories goes something like:
The bin directory contains any necessary DLL files, like SDL.dll, SDL_image.dll and so on. This directory is added to the PATH on my computer.
The include directory contains the headers for the various libraries I use. As you can see, I plopped down the entirety of the Boost 1.32 archive inside the include dirctory. Then both C:\include and C:\include\boost_1_32_0 were added to the include path for my development environments. This allows me to specify my includes in more or less the standard way for each of the libraries. I.e.: #include <boost/smart_ptr.hpp> or #include <SDL/SDL.h>.
The lib directory is where I dumped the source code for each of the libraries that needed to be compiled. Once the libraries are compiled, any DLL files are moved to C:\bin and any LIB files are moved to C:\lib. C:\lib is then added to the library directories for my development environments.
C-+--bin | +--include--+--boost_1_32_0--+--boost | | | +--loki | | | +--SDL | +--lib------+--SDL-1.2.7 | +--zlib121The bin directory contains any necessary DLL files, like SDL.dll, SDL_image.dll and so on. This directory is added to the PATH on my computer.
The include directory contains the headers for the various libraries I use. As you can see, I plopped down the entirety of the Boost 1.32 archive inside the include dirctory. Then both C:\include and C:\include\boost_1_32_0 were added to the include path for my development environments. This allows me to specify my includes in more or less the standard way for each of the libraries. I.e.: #include <boost/smart_ptr.hpp> or #include <SDL/SDL.h>.
The lib directory is where I dumped the source code for each of the libraries that needed to be compiled. Once the libraries are compiled, any DLL files are moved to C:\bin and any LIB files are moved to C:\lib. C:\lib is then added to the library directories for my development environments.
I have an SDK directory:
You can add additional directories to search for include files and libraries.
For VS.Net it's under 'Tools->Options->Projects->VC++ Directories'
This is a better way to do it for two reasons. First you can switch versions easily just by changing the include and library directories, and second it maintains the library prefix in the include. SDL is an exception because its a C library and not organized according to C++ conventions.
An example will demostrate what I mean better.
I would add the directory "D:\SDK\boost_1_32_0" to my include files list.
Then in code I would use:
#include "boost/function.hpp"
But I can change it to boost_1_31_0 if I need to or switch it to the next version when it comes out. If you copy everything into one place, then you don't know that you've removed or replaced all the old files and switching versions is more work as you have to make a copy.
API's ought to be arranged something like this:
<name+version>\name\include files
<name+version>\lib\library bin
The SDL prefixes all it's files with SDL_, so that's how they handle it.
D:\SDK boost_1_32_0 ACE-5.4 SDL-1.2.7 libmkh wxWindows-2.4.2 loki zlib-1.2.1 etc...You can add additional directories to search for include files and libraries.
For VS.Net it's under 'Tools->Options->Projects->VC++ Directories'
This is a better way to do it for two reasons. First you can switch versions easily just by changing the include and library directories, and second it maintains the library prefix in the include. SDL is an exception because its a C library and not organized according to C++ conventions.
An example will demostrate what I mean better.
I would add the directory "D:\SDK\boost_1_32_0" to my include files list.
Then in code I would use:
#include "boost/function.hpp"
But I can change it to boost_1_31_0 if I need to or switch it to the next version when it comes out. If you copy everything into one place, then you don't know that you've removed or replaced all the old files and switching versions is more work as you have to make a copy.
API's ought to be arranged something like this:
<name+version>\name\include files
<name+version>\lib\library bin
The SDL prefixes all it's files with SDL_, so that's how they handle it.
I use pretty much the same method as Shannon and SiCrane, the only difference being i've got a whole partion/drive setup to handle it (over kill I know, but I had a spare external drive laying about and it seemed like a good idea)
As well as the advantages listed above you get teh added bonus of not having to reinstall (the majority) of the files when/if you have to reinstall your dev enviroment, just tell VS.Net the location of the folders and away you go.
As well as the advantages listed above you get teh added bonus of not having to reinstall (the majority) of the files when/if you have to reinstall your dev enviroment, just tell VS.Net the location of the folders and away you go.
Well, I'm not sure if it counts as "managing" but...
I toss DLLs into C:\WINDOWS\System32\
I toss my headers into C:\MinGW\include\API-NAME\
I toss the libraries straight into C:\MinGW\lib\
I do have a major exception in Cygwin, which besides having a few *nix commands installed to allow less molestation of library makefiles (replacing rm with del, etc), also has freetype2 installed through it (which is installed throughout C:\Cygwin\usr\include\freetype2\... and C:\Cygwin\usr\lib\ IIRC).
I do have yet another exception in terms of the APIs I develop myself. I use Eclipse for my IDE, and just use the paths provided by it. This means my headers are usually in:
C:\eclipse\workspace\project-name\include-name\
with only up to the project name being added to my includes path
(e.g. for my SDL wrapper, I have C:\eclipse\workspace\libsdl++\sdl++\system.hh, and to include it I write #include <sdl++\system.hh>)
Then, my DLLs end up in:
C:\eclipse\workspace\project-name\Debug\
C:\eclipse\workspace\project-name\Release\
For the SDL wrapper, the DLL generated is named: "libsdl++.dll", and to link I simply add "sdl++" to my libraries and one of the above paths (depending on the configuration I'm setting up) to my library paths.
I toss DLLs into C:\WINDOWS\System32\
I toss my headers into C:\MinGW\include\API-NAME\
I toss the libraries straight into C:\MinGW\lib\
I do have a major exception in Cygwin, which besides having a few *nix commands installed to allow less molestation of library makefiles (replacing rm with del, etc), also has freetype2 installed through it (which is installed throughout C:\Cygwin\usr\include\freetype2\... and C:\Cygwin\usr\lib\ IIRC).
I do have yet another exception in terms of the APIs I develop myself. I use Eclipse for my IDE, and just use the paths provided by it. This means my headers are usually in:
C:\eclipse\workspace\project-name\include-name\
with only up to the project name being added to my includes path
(e.g. for my SDL wrapper, I have C:\eclipse\workspace\libsdl++\sdl++\system.hh, and to include it I write #include <sdl++\system.hh>)
Then, my DLLs end up in:
C:\eclipse\workspace\project-name\Debug\
C:\eclipse\workspace\project-name\Release\
For the SDL wrapper, the DLL generated is named: "libsdl++.dll", and to link I simply add "sdl++" to my libraries and one of the above paths (depending on the configuration I'm setting up) to my library paths.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
