Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Fetching contributors…


Cannot retrieve contributors at this time

file 83 lines (65 sloc) 3.555 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
The STLport build system

This is a basic overview of the STLport build system. At the moment, I'm only familiar
with the working of the nmake variant, i.e. for MSVC, eVC and ICC/win32, other variants
may differ.


There are three basic classes to consider while building:
1. The used make tool (currently that is make (GNU make) an nmake (Microsoft)).
2. The used compiler
3. The target type, either application or library

Other than that, there are three different settings corresponding to the three different
STLport modes, 'release', 'debug' and 'STLdebug' and each one has two modes for either
static or dynamic linking.

The whole build system lies under the build/ dir of the source tree. There, it first
branches to Makefiles/ (which contains the base of the build system) and to lib/ (which
contains files to build the STLport library) and test/ (which contains files to build
tests) (TODO: what is the misc/ folder for?).

Under Makefiles/, you see the initially mentioned branching according to the build tool.
Here is also where the configure.bat file puts the generated config.mak file. (TODO:
what are the other files in that folder?)


Under nmake/, you then find the common support files for the different compilers and
files that define generic rules. Here, it then splits into app/ and lib/, which are
structured similar to each other and to the common nmake/ dir. In each dir you have
files for the different compilers that are used to make application specific or library
specific settings.

The branching in the three STLport modes and the static/dynamic linking is not visible
in the file structure but only in the used nmake variables.

In order to make clear which file includes which other file, here an example when
compiling the STLport library for eVC4. The call issued is 'nmake /f evc4.mak' in the
build/lib folder. From there, the following include tree is created:

  build/Makefiles/config.mak ; generated by configure.bat
      build/Makefiles/nmake/evc4.mak ; evc4 from config
    build/Makefiles/nmake/lib/top.mak ; would be app/top.mak when building an application
      build/Makefiles/nmake/lib/evc4.mak ; evc4 from config

TODO: build/Makefiles/config.mak is included both by build/lib/evc.mak and by

Known issues:

- nmake: MSC doesn't support generating dependency information for makefiles. So, unless
you modify the direct source file for an object file, no recompilation is triggered! You
need to either delete all object files that need to be recompiled or 'make clean'

- There are targets to only install e.g. the shared STLdebug version but there is no
such thing for making clean. This would be useful in the context of above issue for
making a selective clean only.

Something went wrong with that request. Please try again.