This is not possible, since Jamfile does not have "current" value of any
feature, be it toolset, build variant or anything else. For a single
invocation of A feature has a specific value only when building a target, and there are two ways you can use that value:
The most likely case is that you are trying to compile the same file twice, with almost the same, but differing properties. For example: exe a : a.cpp : <include>/usr/local/include ; exe b : a.cpp ;
The above snippet requires two different compilations of
To solve this issue, you need to decide if the file should be compiled once or twice.
A good question is why Boost.Build can not use some of the above approaches automatically. The problem is that such magic would only help in half of the cases, while in the other half it would be silently doing the wrong thing. It is simpler and safer to ask the user to clarify his intention in such cases. Many users would like to use environment variables in Jamfiles, for example, to control the location of external libraries. In many cases it is better to declare those external libraries in the site-config.jam file, as documented in the recipes section. However, if the users already have the environment variables set up, it may not be convenient for them to set up their site-config.jam files as well and using the environment variables might be reasonable. Boost.Jam automatically imports all environment variables into its built-in .ENVIRON module so user can read them from there directly or by using the helper os.environ rule. For example: import os ; local unga-unga = [ os.environ UNGA_UNGA ] ; ECHO $(unga-unga) ; or a bit more realistic: import os ; local SOME_LIBRARY_PATH = [ os.environ SOME_LIBRARY_PATH ] ; exe a : a.cpp : <include>$(SOME_LIBRARY_PATH) ;
For internal reasons, Boost.Build sorts all the properties alphabetically. This means that if you write: exe a : a.cpp : <include>b <include>a ;
then the command line with first mention the exe a : a.cpp : <include>a&&b ;
The On Unix-like operating systems, the order in which static libraries are specified when invoking the linker is important, because by default, the linker uses one pass though the libraries list. Passing the libraries in the incorrect order will lead to a link error. Further, this behaviour is often used to make one library override symbols from another. So, sometimes it is necessary to force specific library linking order.
Boost.Build tries to automatically compute the right order. The primary
rule is that if library lib a : a.cpp b ; lib a : a.cpp : <use>b ;
The same approach works for searched libraries as well: lib z ; lib png : : <use>z ; exe viewer : viewer png z ;
The local gtk_includes = [ SHELL "gtk-config --cflags" ] ;
You might want to use your project's root location in your Jamfiles. To access it just declare a path constant in your Jamroot.jam file using: path-constant TOP : . ;
After that, the
If one file must be compiled with special options, you need to explicitly
declare an exe a : a.cpp b ; obj b : b.cpp : <optimization>off ; Of course you can use other properties, for example to specify specific C/C++ compiler options: exe a : a.cpp b ; obj b : b.cpp : <cflags>-g ; You can also use conditional properties for finer control: exe a : a.cpp b ; obj b : b.cpp : <variant>release:<optimization>off ;
Before answering the questions, let us recall a few points about shared libraries. Shared libraries can be used by several applications, or other libraries, without physically including the library in the application which can greatly decrease the total application size. It is also possible to upgrade a shared library when the application is already installed.
However, in order for application depending on shared libraries to be
started the OS may need to find the shared library when the application is
started. The dynamic linker will search in a system-defined list of paths,
load the library and resolve the symbols. Which means that you should
either change the system-defined list, given by the
An executable can include a list of additional library paths, which will
be searched before system paths. This is excellent for development because
the build system knows the paths to all libraries and can include them in
the executables. That is done when the
Obviously, installed executable should not contain hardcoded paths to your
development tree. (The install installed : application : <dll-path>/usr/lib/snake <location>/usr/bin ;
will allow the application to find libraries placed in the If you install libraries to a nonstandard location and add an explicit path, you get more control over libraries which will be used. A library of the same name in a system location will not be inadvertently used. If you install libraries to a system location and do not add any paths, the system administrator will have more control. Each library can be individually upgraded, and all applications will use the new library. Which approach is best depends on your situation. If the libraries are relatively standalone and can be used by third party applications, they should be installed in the system location. If you have lots of libraries which can be used only by your application, it makes sense to install them to a nonstandard directory and add an explicit path, like the example above shows. Please also note that guidelines for different systems differ in this respect. For example, the Debian GNU guidelines prohibit any additional search paths while Solaris guidelines suggest that they should always be used.
It is desirable to declare standard libraries available on a given system.
Putting target declaration in a specific project's Jamfile is not really
good, since locations of the libraries can vary between different
development machines and then such declarations would need to be
duplicated in different projects. The solution is to declare the targets
in Boost.Build's project site-config ; lib zlib : : <name>z ;
Recall that both exe hello : hello.cpp /site-config//zlib ; in any Jamfile. In modern C++, libraries often consist of just header files, without any source files to compile. To use such libraries, you need to add proper includes and possibly defines to your project. But with a large number of external libraries it becomes problematic to remember which libraries are header only, and which ones you have to link to. However, with Boost.Build a header-only library can be declared as Boost.Build target and all dependents can use such library without having to remeber whether it is a header-only library or not.
Header-only libraries may be declared using the alias my-lib : # no sources : # no build requirements : # no default build : <include>whatever ;
The includes specified in usage requirements of
If you already have proper usage requirements declared for a project where
a header-only library is defined, you do not need to duplicate them for
the project my : usage-requirements <include>whatever ; alias mylib ;
|