The goal here is to explain to developers how to build the 0.5 version of the OSDL library for Windows, on Windows (no cross-compilation).
|
Note: the Windows port of the OSDL toolchain is generally lagging behind the GNU/Linux development version. We regularly fix the various small issues that affect the Windows build, but quite often the ongoing newer developments on GNU/Linux result in a broken source tree for Windows. In that case just notify us that something went in the way of the Windows version, and we will do our best to fix it quickly.
|
If a user just needs the OSDL DLL so that she can run an executable depending on the OSDL library (only OSDL-0.5-from-LOANI-release-mt.dll and its prerequisite DLL
are required), then she can download, if available, a LOANI prebuilt user package from
OSDL File Releases on Sourceforge (search for LOANI-0.5-prebuilt-for-windows-users.zip). Should an up-to-date archive be unavailable, ask us and we will add it quickly.
If a user just wants to develop a program or a library depending on the OSDL library (hence needing OSDL installed headers, and preferably OSDL-0.5-from-LOANI-debug-mt.dll and OSDL-0.5-from-LOANI-debug-mt.lib, same for the OSDL prerequisites) and does not wish to build OSDL by herself, then she can download, if available, a OSDL prebuilt developer package from
OSDL File Releases on Sourceforge (search for LOANI-0.5-prebuilt-for-windows-developers.zip). If an up-to-date archive is not available, please
ask us and we will add it quickly.
If you are still reading, then it is that you really want to build the OSDL library by yourself. This is the recommended way.
Here the target platform is Windows XP, be it Home or Professional edition. Note that we will not have any link with the .NET framework.
The first reading should be the tool section of the Ceylan counterpart guide, which gives detailed information about the generic conventions we use to build our developments on the Windows platform.
One has to have applied the steps about the tools described in this document before going on with this one: both Ceylan and OSDL use SVN (hence depend on TortoiseSVN), are built with Visual Express, rely on Cygwin, make and al to drive the build process, launch Visual Studio, automate the test suites, and so on.
As OpenGL is used by OSDL, one should install first the latest stable (OpenGL) drivers for one's graphics card. Just look at the name of your card from the Windows hardware device panel, and search the corresponding drivers in the website of the card manufacturer. Download and install.
SDL needs to have the DirectX SDK installed. Prepare to download a lot, for example the size of the June 2008 SDK version is about 460 megabytes. Default path settings are fine.
Most of the task will be to retrieve and build the various OSDL prerequisites. Luckily, we designed a light-weight command-line tool, LOANI, to automate the process.
This script is cross-platform, it can be used both on native UNIX platforms and on Windows platforms, as long as they have Cygwin installed.
On these Windows platforms, the script automates everything it can, but it still needs to be interactive, as some steps could not be performed without user specific actions (on UNIX platform the LOANI script is fully automated though).
More precisely, the Windows user may have to perform a manual SVN update of Ceylan and/or OSDL repositories. This is because of a limitation of the Cygwin SVN command-line tool, that cannot handle long pathnames (low MAX_PATH constant). As long as this tool will not be fixed, the automated checkout may fail, and the user will have to complete it thanks to TortoiseSVN. The script will explain what to do, should this situation occur.
The second - and last - kind of operation requiring the user intervention is when a source package has to be built: as we are using the Visual Express IDE, one has to trigger the builds from the GUI. Luckily enough, for each package, the script will automatically run the IDE with the proper arguments, so that the user will have only to right-click the solution, in the Solution Explorer panel, to select Regenerate the solution, and let the build take place before one's last action, closing the IDE and letting the LOANI script continue.
To ensure the package was correctly built, as expected, one can check that nothing failed in the Visual Express output window. This should be the case, apart on some rare occasions for a few Ceylan test cases: depending on the length of the path where the user chose to install OSDL and al, Visual Express tool mt may fall into a problem with long pathnames (again!).
Due to the use of Visual Express, the user will be prompted to trigger, for each package, the corresponding build.
|
That's it! You should have, once LOANI has finished, everything needed to make good use of the OSDL library. In case of problem, re-read everything carefully (this document, the OSDL user guide, the LOANI guide) and should the problem persist, send us a mail.
For in-depth technical details about Windows-specific inner workings of OSDL and its prerequisites, one may continue the reading.
Most people will stop and continue by using by themselves the library.
|
For all packages (OSDL and its prerequisites), LOANI has totally revamped the legacy project files (if any), so that they are up-to-date, in latest Visual Express format, and integrated alltogether: each library has its OSDL-specific precooked solution.
The full build process of all packages thus is parametrized from centralized property sheets (src/conf/build/visual-express/OSDLProperties*.vsprops). This file is made to be included by all project solutions. It allows to change them as a whole, once for all. This is very convenient for example when switching between debug and release modes: all libraries in the full dependency tree ought to use the same system libraries, for example DLL Multithread Debug Library. Do not use the NODEFAULTLIB switch, it only hides the problem.
One should look at this page for additional explanations about SDL build.
SDLmain.lib should not be forgotten when linking to SDL's DLL. It is a trick to convert a basic main() into a suitable Winmain in the Microsoft fashion.
One pitfall: the code uses lrint, which is not available on Windows. The work-around has been to define a pre-processor macro lrint=floor.
Adapted from its Ceylan counterpart.
Visual C++ -> General -> Empty Project
testOSDLBasicResourceManager for source in basic/testOSDLBasicResourceManager.cc. Note that the initial project name is not basic-testOSDLBasicResourceManager, so that the associated files and directory names remain short
trunk/test/basic for testOSDLBasicResourceManager
testOSDLBasicResourceManager.cc, which should lie in the parent directory of the one of this testsrc/conf/build/visual-express), the OSDLProperties.vsprops file. Then (in that order), do the same for OSDLPropertiesForTests.vspropsCommon Properties -> References, click on Add New Reference and select OSDL-0.5 library
testOSDLBasicResourceManager becomes basic-testOSDLBasicResourceManager. It allows to sort the projects in the IDE panel without having the long names in the filesystemtrunk/test/basic/testOSDLBasicResourceManager directory, and select only testOSDLBasicResourceManager.vcprojIf you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!