C++ boost library and Boost.Build ports building info

I'm glad to see the last version of boost libraries in the ports, I upgraded them and boost_build in early february, everything seemed to be going well untill yesterday. I would prefer to contact the port maintainer for this, also to clarify me something about port makefiles in boost-all, boost-libs and boost_build. The port maintainers are office and ports (at freebsd.org), I guess the unassigned maintainers.

What's best, post here what's in my mind or try to contact the port maintainers?

Who intrested to link against boost libraries with c++11 std, add this to /usr/ports/devel/boost-all/compiled.mk or you will get link errors. Better to add a port option, in any case I don't see side effect having the libraries compiled with this clang flag, with gcc will get errors, though.


The lines below, with comment, should remove the -O flag but it don't, I'm trying to solve this. Anyhow the bjam cxxflags here, overwrite the one in the .if ${ARCH} == amd64 conditional or at least it puts 2 cxxflags option on bjam command line.

About boost_build (and boost-jam) it's very strange, I never separated bjam and its own environment settings. In Windows have a complex script to compile libraries and builder (bjam), it's not complicated to compile them, it's complicated to compile them in a temporary directory for 64 and 32 bit, and then copying each component (headers, libraries 32 and 64 bit, binary tools and their environments) in the right directories (for my needs).

The bjam tool is part of the whole distribution (<ROOT>/tools/build/v2), on ports it's dwnloaded from sourceforge, but the files are very different, it seems it's very old respect the one in boost distribution. It lacks clang compiler support (if I remember starting from 1.53.0 version). Anyhow, when I compile bjam in Windows (not the preferred boost platform), the executable (bjam) and all the environment files are copied into the directories bin and share under the root specified by the option --prefix.

Therefore, I see no patches to apply to all the boost-* ports, so I install all components without using ports, if it works I will try to modify the port Makefiles, but it whould be better if the this step is done by a port expert (I hope this sentence is understandable). Last thing, I never compiled it (on Windows) with ICU, MPI and zlib libraries, yes once, I don't remember what version it was, it was long time ago, but it should not be difficult to do it on FreeBSD, also I will try with both clang and gcc compiler. Good luck.

I'm open to any suggestions, criticism & Co.

I think I have to do the same things as in Windows, compiling and installing in a separate directory tree. I can compile boost libraries and build tools in a separate prefix tree, boost in ports tree is used by other ports (required dependency), so it's better I leave all boost ports as they are and execute my sh script to have a separate development boost.

I understood something more about makefile structure in ports tree, some artifacts are still in the darkness (expecially some make variable substitution/manipulation hierogliphs), one thing I do not understand: the library use iconv, in the makefile it's added into bjam process, but I did not understood if it require the port libiconv or the system one, I guess it use the system one, pkg info -r libiconv don't list boost-* in 'required by' ports.

Maybe the ports devel/boost-jam and devel/boost_build can be joined or integrated with boost-libs, that is the Boost.Build tool is always build and present if boost-libs is installed. Or at least keep it separate but use the Boost.Build in the distribution tarball. I uninstalled the Boost.Build ports and actually use the one I compiled (they are installed under my non root user home directory sub-tree).