referencecompilers [www ibpp org]


ďĹĽ

reference:compilers [www.ibpp.org]










[[reference:compilers]]

http://www.ibpp.org/












 


You are here: ibpp  reference  compilers


Table of Contents



Compilers

Which
Files To Integrate

What
Compiler Options / Settings To Use

Which
Compilers Are Reported To Be Working for IBPP

Compiling
The 'tests' Programs
Compilers

This is a short documentation instructing you how to integrate IBPP source
code in your own projects. It is basically the same information as what is
available in the â€Ĺšhowtobuild.txt’ file.
Starting with version 2.5 IBPP does not provide anymore a stand-alone build
procedure. IBPP is a set of C++ classes. A small hand of .h and .cpp files
implement them. You might wish to compile them separately in a lib, then use the
lib in your own programs, but it is as well easy, if not easier and safer, to
properly integrate IBPP source core inside your own applications build
procedure. Here are guidelines to help you do that.
Which Files To
Integrate

Choose a proper location in your own source code tree of folders and files to
host the ibpp files. A good idea would be to create a folder named â€Ĺšibpp’ where
you see fit. Now unzip the distribution archive to that ibpp folder.
In that ibpp folder you will find some *.txt files. There will also be a
sub-folder named â€Ĺšcore’. It has all the files you need to integrate to your
build procedure. All the other folders are only there to support the development
and testing of ibpp itself. You don’t need to compile and link anything else
than what is in the â€Ĺšcore’ folder to your own application.
An alternate way, if you have for instance multiple programs which all use
ibpp, would be to host the â€Ĺšibpp’ folder in a common place to all these programs
and simply reference those â€Ĺšibpp/core’ files at that common location from your
multiple build procedures.
Out of the files which are located in the â€Ĺšibpp/core’ folder, â€Ĺšibpp.h’ is the
only one which you will need to #include from your own code files which use ibpp
interfaces. That may be all your files, or only a subset of them. Wether you
include the â€Ĺšibpp.h’ file from another central header file of your project, or
locally from within each code file which use ibpp does not matter.
All the other code files (*.cpp) of the â€Ĺšibpp/core’ folder (except
â€Ĺšall_in_one.cpp’) must be compiled and linked with your application as if they
were original portions of your application. There are less than 20 code files,
this is very easy to add to your Makefile, or visual project file. In a Visual
Studio Project, you might conveniently add a â€Ĺ›group” (or â€Ĺ›filter”) named â€Ĺšibpp’
and there â€Ĺšadd’ the existing .cpp files from the â€Ĺšibpp/core’ folder. It is
probably even more straightforward to do in your existing Makefile on unix
systems. To simplify further, you can as well only reference the
â€Ĺšall_in_one.cpp’ file in your build projects. That single file conveniently
include all others.
All the header files (*.h), other than â€Ĺšibpp.h’ itself are included by one or
multiple of the core code files. They are NOT included by â€Ĺšibpp.h’ itself. You
should not have anything to do regarding those files. They should be found
automatically while compiling the core source files (because they are in the
same directory than the code files themselves).
What Compiler Options / Settings To
Use

Generally speaking, don’t tamper with the settings of your own projects just
for the purpose of compiling in and linking in ibpp. The advantage of
integrating ibpp source code in this manner is precisely here : it helps be sure
that the ibpp code has been compiled in a compatible manner with all the code of
your application. At the cost of setting up ibpp inside your build procedure you
will quickly discover that it brings you multiple advantages. Switching between
debug and release builds is easier. The ibpp code follows yours, as if it was
your own code. Finding source files while debugging is generally automatic,
making for easier debugging sessions where you can trace execution inside ibpp
code itself very easily. Your compiler or linker might even find more
opportunities for optimizations in such a setup.
Despite the generic above recommendation not to tamper with your own
settings due to ibpp, there are some things you need to do though.
First and foremost, ibpp requires C++ Exceptions and RunTime Type Information
to be supported and enabled in your compiler. These are part of the C++ Standard
and as such, no modern compiler should have C++ Exceptions and Runtime Type
Information disabled by default. If they happen to be disabled, you will have to
enable them, at the least for all ibpp code files and for all of _your_ code
files which do include and use ibpp.
Second, ibpp use the C++ Standard library (a very minimal subset of the STL
part of it, indeed). Again that should not require you to turn on a switch on
your compiler, but if you need to, you have to do so.
Third, all ibpp/core files and your files which use ibpp interfaces
must be compiled with some defines. You can define the required
values on the compiler command-line (through Makefile for instance) or insert
those in the properties of your visual projects. You can also #define them
somewhere at an appropriate location in one header file of your project, but you
have to define them. They drive some conditional code inside the source code of
IBPP. Those required preprocessor definitions start in â€Ĺ›IBPP_” so they are
likely not to conflict with any existing definitions in your own code. To keep
things simple, you might want to globally compile all of your application code
with those definitions, no matter if they use or reference ibpp or not. It
should not harm anything to do so.
The required prepocessor definitions are documented near the top of the
ibpp.h header file. Please review it for the details. Currently only one define
is used to select the platform. To the contrary of previous IBPP versions, the
compiler is auto-detected by recognizing some hard-coded predefined macros
provided by each supported compiler.
That’s all!
Which Compilers Are
Reported To Be Working for IBPP

Well, a lot of compilers and environment indeed. The IBPP source code has
very minimal needs to interface to your system. It is then largely portable C++
Standard code. You will find very few conditionals inside IBPP source code.
Generally speaking, any modern C++ compiler should be okay.
IBPP is known to be useable or in useage on the following platforms and
compilers. The real list is probably much longer.


Nearly all Linux or Unix
systems using GCC 3.2 or higher, wether big-endian or
little-endian. This also include Mac OS X â€Ĺšdarwin’ system.

Nearly all significant Windows compilers,
provided that they have a decent C++ Standard library implementation or can be
fitted one optional correct one. This at least includes Visual Studio
2005, 2003. Microsoft Visual Studio
6.0 does not qualify as a modern, standard compliant compiler, though
it is still supported as of versions 2.5.x of IBPP. That may not be true of
any future version though. Add to the list of supported compilers:
Borland C++ Builder 6, the Borland free C++
compiler, cygwin, mingw,
dmc (Digital Mars Compiler).

All these, on 32 bits or 64
bits platforms, provided that the compiler and environment supports
it.
Compiling The 'tests' Programs

The tests programs are located in the â€Ĺšibpp/tests’ folder. You never need to
compile those tests programs as part of your applications. That code is NOT part
of IBPP. It is part of the project because it is used to run the most basic
tests when developing IBPP itself. You can of course build the tests programs in
order to verify that IBPP works correctly with you installed server.
Compiling the tests program is easy. It merely needs to compile and link the
tests.cpp file along with those of the â€Ĺšibpp/core’ folder. To make things easier
and to give samples of build procedures showing integration of IBPP in another
application build system, you will find various procedures in sub-folders of the
â€Ĺštests’ folder.


unixes: contains a Makefile which should build
the tests executable without issues, out of the box, on most linux and unixes
systems. At least those where IBPP was tested at least once.

bcb6: contains both a visual project and a
â€Ĺšsimplest-build.bat’ file, which target Borland C++ Builder 6 (visual or
command-line compiler). The â€Ĺšsimplest-build.bat’ file is really dumb but shows
that there is no black magic in compiling IBPP code along with your
application code.

vs6: contains a visual project, which target
Microsoft Visual Studio 6 (SP6).

vs2005: contains both a visual project and a
â€Ĺšsimplest-build.bat’ file, which target Microsoft Visual Studio 2005 (visual
or command-line compiler). The â€Ĺšsimplest-build.bat’ file is really dumb but
shows that there is no black magic in compiling IBPP code along with your
application code. It should work too for Visual Studio .NET 2003 and possibly
for Visual Studio 6.0.




reference\compilers.txt · Last modified: 2006/03/30 18:07 by
olivier










 






Wyszukiwarka

Podobne podstrony:
referenceeventinterface [www ibpp org]
referencetimestamp [www ibpp org]
reference [www ibpp org]
referenceevents [www ibpp org]
referencesamples [www ibpp org]
referenceexceptions [www ibpp org]
referencearray [www ibpp org]
referenceblob [www ibpp org]
referenceclientlibsearchpaths [www ibpp org]
referencedate [www ibpp org]
referencetime [www ibpp org]
referenceguidelines [www ibpp org]
referenceconversions [www ibpp org]
referencedatabase [www ibpp org]
referenceuser [www ibpp org]
referencetransaction [www ibpp org]
referencestatement [www ibpp org]
referenceoverview [www ibpp org]
referenceservice [www ibpp org]

więcej podobnych podstron