
On 30/3/2011 10:36, Artyom wrote:
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad.
So Boost end users should *not* be the primary audience!
Actually I must admit it is wrong statement. Why? Because the libraries may be much more complicated then you think.
Especially when it comes to handling DLL's where you need a special defines for DLL build.
But this is only 5% of the problem.
If you try for example build boost-system or other relatively simple libraries that do not have any external dependencies it is simple.
Now when it comes to iostreams or regex it becomes more complicated (zlib, bzip2 and icu)
Now lets take few other libraries that are now in review queue:
- Boost.Context - it has platform/compiler conditional assembly sources and separate build options to use ucontext or fcontext.
Do you really think it is possible to give a user sources and say compile them?
- Boost.Locale - it depends on several libraries: ICU, iconv and boost-thread conditionally has 5 build options (with/out icu,iconv,win32api,posix-api, std-locale-api) and some of them should be turned conditionally for different platforms.
So no I don't expect user to do all the job for me. This is why build system exists.
Boost is lucky because its libraries and build are relatively simple. and before anybody screams about how sophisticated boost is I add
- Almost no compile time configuration (something like generated config.h) - Almost no 3rd part dependencies. - Almost all configuration is done by ifdefs instead of configure like scripts that can test features automatically and not require from user to know every possible OS/Compiler setup.
So that is why Boost.Build suites somehow Boost and in general this is why build system exist.
Absolutely.
A friend of mine that works with MSVC Projects only do not understand all buzz around makes/cmakes/autotools/bjams and so on because he writes software for one compiler and one platform... So MSVC projects suit him.
Even then I would probably use CMake to automate finding of External libs (i.e. Boost), especially if one has several subprojects.
But in real world Build system is essential part of any project.
+1 Especially for Library development, where the user is always also developer. regeards Fabio