D 2017-12-20T17:32:23.362
L Configuration
P 11519c16ef50699f97615735d845b1b3855c1810
U luismachuca
W 5417
The <i>cxxomfort</i> library should hardly require configuration depending on the compiler and system you use. However as of 2017 only GCC 4.6 ≤ < 6.0 and MSVC 2008 / 2010 are *officially* tested for. More information will be added here as more compilers are tested.
<h2>General configuration procedure</h2>
The key element to configure this library is to make sure that TR1 (for C++03 mode) is supported correctly and the headers work in a manner similar to how they work in C++11:
# For C++03: The TR1 headers must be able to be <code>#include</code>d directly - by name only (such as <code>#include <array></code> instead of <code>#include <tr1/array></code>). Make sure adequate support for TR1 is enabled and the TR1 path is added to the compiler/project's <code>#include</code> path.
# Add the <i>cxxomfort/</i> path to your compiler/project's <code>#include</code> path.
<b>If your compiler does NOT provide TR1:</b>
(I'm looking at you, MSVC 2008 Express)
You <i>might</i> be able to get past it by installing a third party TR1, such as Boost's, provided it supports at least array, tuple and type_traits. Such configurations are not supported officially and not tested for, however.
<hr/>
<h2>Configuring GCC</h2>
To add the path to a compile command, use the <code>-I</code> or <code>-isystem</code> switches:
<verbatim>
g++ [...options] -I /path/to/include/cxxomfort/ [...sources]
</verbatim>
<b>(The following information applies only to C++03 mode)</b>
GCC incorporates the TR1 headers (<code><array></code> etc) in the <code>tr1/</code> subdirectory. Unfortunately, because of the way the headers themselves are coded, they don't work when they are added to the compiler <code>#include</code> search path. See [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36428|GCC bugzilla] and [http://lists.gnu.org/archive/html/adonthell-general/2011-07/msg00006.html|report about stl_list.h] for more general information. The tl;dr of the problem is that adding TR1 to the <code>#include</code> path causes ambiguity errors in declarations that can not be solved without patching the <i>non</i>-TR1 headers themselves, such as <code>stl_list.h</code>.
Since GCC considers Tr1 "not worth fixing", which given its age makes sense, it is instead recommended to use a <b>TR1 forwarder</b> such as [http://chiselapp.com/user/lmachucab/repository/tr1_fwd|tr1_fwd], which is the supported an tested-for configuration in GCC C++03 mode. Alternatively, one can use an alternative Tr1 implementation such as <b>Boost.Tr1</b>.
<b>Alternative: Patching system headers [note]</b>
If one does not wish to add further dependencies to the project, and due to the way the TR1 headers are themselves coded, the way to skirt around the issue is to make sure that code that uses the ambiguous symbols (in <code>stl_list.h</code> among others) is somehow made to see only the base implementation required and not the TR1 one.
There are two ways around this issue detailed in the following issue: <em>(link pending)</em>:
* patch <code>stl_list.h</code> and other such files to refer to the namespace or object by full name, or...
* Make sure that the system headers affected such as <code><list></code> are #included into the priject <i>before</i> <code>cxxomfort/cxxomfort.hpp</code> - but after <code>cxxomfort/base.hpp</code>.
Of note however, trying this is <b>NOT</b> recommended and not supported; the alternative is offered here only so that it is available in extreme cases where it can not be done.
<h2>Configuring with clang</h2>
Use the <code>-I</code> switch to add to the compiler path:
<verbatim>
clang [...options] -I /path/to/include/cxxomfort/ [...sources]
</verbatim>
For the most part this will be setup and work exactly as it does in GCC; however, it might be necessary to patch a couple of header files from the tr1/ implementation if using clang alongside <b>GCC 4.6 or earlier</b> (<small>more specifically, to deal with the declarations of some of the new <code>cmath</code> functions</small>). Patching the libraries so falls outside the scope of this document.
<h2>Configuring with MSVC</h2>
Use the <code>-I</code> switch to add to the compiler path:
<verbatim>
cl.exe [...options] -I /path/to/include/cxxomfort/ [...sources]
</verbatim>
<b>(The following information applies only to MSVC 2008)</b>
MSVC 9 (2008) Express does not ship with a tr1 implementation, thus lacks, among the most important features, a <code><type_traits></code> implementation. This is partly solved by cxxomfort providing its own type traits, but this should not be relied upon by client programs. cxxomfort code using features from <code><functional></code> will most likely fail to compile without an alternative TR1 implementation.
Some sources say the <u>MSVC9 Feature Pack</u> can be installed to provide a working tr1 implementation; however this can not be installed in 2008 Express and thus Feature Pack setup is <u>not</u> tested or coded for; if using Express, it is up to you to provide a working TR1 implementation via boost, stlport or similar (tests were run via a pared down version of Boost.Tr1).
On the other hand, MSVC 2008 Express <b>SP1</code> comes with a partial, but working for our purposes, TR1 implementation.
<hr/>
* ← Back to [Installation].
* → Continue to [Features].
Z 417eb274099d01832408a65535906624