Is it possible to do an out-of-source build using Jam? If yes, how?
(I've been sifting through the manual, but it makes no mention of this as far as I can see.)
Note: I am using the "standard" Jam v2.5.
This might depend on the version of jam you are using. Speaking for the standard jam (i.e. not the Boost or FreeType forks): There is no official way, but you might get away with:
jam -sJAMFILE=path/to/Jamfile ...
For more complex build systems that also have a configure stage, I'd recommend to simply generate a minimal Jamfile in those output directory/directories from which you intend to invoke jam.
Related
I pretty new to C++. I was wondering, as what is considered generally a neat way to provide paths for various files/libraries while compiling or executing c++ codes.
For ex:
I have Boost libraries installed in some location on my system. Lets call it X
In order to execute anything I have to type in
c++ -I LongpathWhichisX/to/boost_1_60_0 example.cpp -o example
Similarly, also Long path for the input file while executing the code.
Is there a better way to address it. Is it possible to create environment variables lets Y, which refers to path 'X'. And we can use following command to compile code
c++ -I Y/to/boost_1_60_0 example.cpp -o example
Best way is to use build tools. For example you can use Make. You define all your include paths (and other options) in the Makefile. In console you just have to call make to build your project or something like make run to run your project.
The usual way is to make a Makefile where you can specify all needed paths and compile options in proper variables.
If you don't want/need a Makefile and rather want to run compiler from command-line, then you may use the CPATH environment variable to specify a colon-separated list of paths to include files.
This is a broad question but the other answers highlight the most important step. It is essential to learn build tools like make because they will make it easier to build your projects during development and for others to build it later. In the modern programming age though this is not enough. If you are using something like Boost (which targets many platforms) you will probably want to make your build cross-platform as well. For this you would use either cmake or autotools which both have scripts that make it much easier to locate the Boost libraries (and others).
Any other build systems, in my opinion, are a pain and are the bane of maintainers of Linux distributions. CMake used to be in that catergory but it has gained wide acceptance now. CMake targets building cross-platform projects across operating systems (Windows and Unixes) better (again in my opinion) because it attempts to provide the native build system on each platform (for example: Visual Studio in Windows, Make on all Unices, XCode on Mac). The autotools instead target the Unix environment with much greater depth (you have a bit of a harder time on Windows, but you can target embedded Unix systems to high end Unix server systems with much more flexibility).
Note: Autotools support for cross-compiling is superior in almost every way to other solutions. I always cringe when I download something that needs to be cross compiled for Arm Linux and it uses some weird build system. Funnily enough, boost is one of these.
This is a bit of a long winded answer. In summary, it is essential that you learn a build system for native development. It is part of your skill set and until you have that skill you can't really contribute to open-source projects or even your employer developing closed-source projects.
I want to conditionally compile some c++ code that uses boost, and make it so it doesn't try to compile the boost dependent code if boost is not present.
Does boost have any global macro that will be defined, like __BOOST__, that I can check for?
EDIT: It's clear to me now that I have to achieve this on the makefile level. I am working on OSX lion. Using gnu make
The TYPICAL way that this is done is to use a "configuration script" or similar, that detects if the required/optional component(s) is/are present, and then selectively sets some -D options to the build system.
Obviously, if it's just your own project or a small distribution, you could do the same thing manually.
You probably also need a couple of ifdef type of choices in the Makefile if there are library files that you need.
One of the easier ways to determine if a part of boost that you need is installed is to try to compile it. If there are errors, the likely cause is that that part of boost isn't present (this obviously doesn't work if there are more important parts missing - for example, not having a compiler or standard library installed will ALSO cause a compile to fail. This is why nearly all configure type tools "start with the most basic features, and work their way up the tree of dependencies").
I want to use Boost.Thread library in a C++ software that I'm developing.
Since I'm a complete newbie in C++, I would like to know if there are any differences between:
Downloading and building Boost manually for MSVC9-x64
Using a pre-built package: http://boost.teeks99.com/
Option 1 seems so painful...
As far as I can tell, these are the default builds and not from patched or tweaked sources or anything.
If you take care to use the correct version of binaries for your application target and version of VC (including service packs) and link against the correct libraries (shared, static CRT, debug, etc.) you should be absolutely fine.
Also, since it seems that these packages don't contain Boost headers, you must take care to get and use the correct version of headers.
Concerning the "differences". Boost is a large and complex collection of libraries. For a software of that size, it has a quite simple and straightforward build process, but still, there are many options and customizations you can do when building Boost (e.g. you can build Boost.Iostreams with or without zlib and bzip2 support, build Boost.Regex with or without Unicode support, build Boost.Python against different versions of Python, and much more.) When you build Boost, you have control over these options.
The defaults work for most people, but some people may need certain customizations. You might want a specific version of a specific optional dependency, or a certain library built a certain way. For that, you probably will need to build Boost yourself and maintain the build throughout your project. This is not a scary task!
If you don't have any special requirements, then a generic build would most probably be fine for you.
I'm working on a c++ project, and we recently needed to include a small part of boost in it. The boost part is really minimal (Boost::Python), thus, using bjam to build everything looks like an overkill (besides, everyone working on the project feels comfortable with make, and has no knowloedge of jam).
I made quite some tests already, but I cant find a way to include the formerly mentioned library in my makefile and make the build succesful.
All your help is deeply apreciated. :)
You can use Boost's bcp utility to extract only the subset of Boost you need.
That will minimize your build time & size.
That doesn't answer your question, though. You may want to consider building the Boost.Python libraries separately and checking them directly into your source control system. Then nobody would need to build them.
I had the same problem and found a solution in this tutorial. You 1) need to compile the source into an object file with the -fPIC gcc option, and 2) compile this object into a library with the -shared gcc option. Of course you have also to link against the Boost.Python library (generally -lboost_python, however for my debian system it is for example -lboost_python-mt-py25, I have also to add -I/usr/include/pythyon25). In my makefile I end up doing those two steps in one command. See also p. 13 of this presentation.
If you're uncomfortable with bjam, you might want to consider using Boost.Cmake.
Alternatively you should at least be able to see more easily what they are doing then with the bjam files.
Run bjam from the makefile, just for building that part
When writing an app that one wants to have compile on mac, linux and windows, what is the best way of managing the different libraries that will need to be included on the various operating systems. For example, using the glut opengl toolkit requires different includes on each operating system.
Your question is actually two questions in one:
1) How do I write my C++ code to include the right include files on the right platform?
2) How do I write my Makefile to work on different platforms?
The C++ code question is already answered - find the platform-specific defines and use them to figure out what platform you're on.
Automake or scons are quite complex, and are worth your time only if you intend to release your code to a wide audience. In the case of in-house code, a "generic" makefile with per-platform include is usually sufficient. For Windows, you can get GNU Make for Windows (available from here, or use nmake and limit yourself to the subset of syntax common between all platforms.
If you just need to worry about header files, then the preprocessor will do everything you need. If you want to handle differing source files, and possibly different libraries you'll need a tool to handle it.
Some options include:
The Autotools
Scons
CMake
My personal favorite is CMake. The Autotools uses a multi-stage process that's relatively easy to break, and scons just feels weird to me. Cmake will also generate project files for a variety of IDEs, in addition to makefiles.
There is a good article on Macros. One of the answers how to use conditional compilation based on OS/COmpiler (its near the top).
The use of the Autoconfiguration tools is a nice addition on top of this but is not needed for small projects where it may be easier to detect the OS explicitly, though for larger projects that may need to run on many different types of OS you should also explore the Available autoconfiguration tools mentioned by Branan
Several projects I've worked on use an autoconf-based configure script which builds a Makefile, hence the reason you can build all of them from source with a simple:
./configure
make
make install
Scons has a configuring mechanism that will do a lot of what autotools do without as much complexity, and is pretty darn portable (although not as portable as autotools).
The compiler should have a set of preprocessor symbols it will provide that you can use. For example linux for gcc on a Linux system, _WIN32 for VC++. If you need something more complex then look at autoconf, but that works best for Unix based code.
I'd recommend checking out how some of the larger OpenSource projects handle this. See AutoSense.hpp from (an old release of) Apache Xerces.
If the libraries offer the same API on the different platforms, I would create a "proxy" include file containing all the necessary #ifdefs. That 'platform-independent' include file is then included in your client code instead of cluttering it with numerous and ugly-reading preprocessor commands. These will be contained in the ugly and cluttered platform-independent include.
If the API differs across platforms, you will need to create your own abstraction.
Perhaps this is a cop-out answer, but have you looked at how boost handles this? They build on quite a few platforms without autoconf, although they do have their own build system - bjam - that probably handles some of the same situations. They also do a nice auto-linking trick on windows that automatically selects the right version of libraries for linking depending on the version of the MSVC compiler. Based on your initial description, it sounds like just macro defs checking for various platforms/compilers might do the trick, but perhaps there is more to your problem that would prevent this.