[cctbxbb] changes to cctbx we have in ccp4

[Marcin Wojdyr]

Hi All,
we have a bunch of changes to cctbx in ccp4. If any of them are of
general interest I can push them to svn. They'd need some cleanup
before applying, so I'm not attaching any patches for now.

- option to use external Boost. It's the same what debian and gentoo
distros are doing when packaging cctbx. We change a few lines in the
scons scripts and rm cctbx_project/boost/* (but the boost directory
itself must be present). We could add an option for it
(--use-system-boost ?).

- removing -funroll-loops - this option must be a historical leftover.
Generally it's better to let compiler decide because unrolling loops
may make the program slower as well as faster. I tested it on Phaser a
couple years ago. The only noticeable effect of this flag was much
bigger binary.

- extend --use-environment-flags to handle also CC and CXX. With most
of makefiles / build scripts, if the user has multiple compilers
installed he selects one with CC=gcc-mp-5 etc. Then if the build
script really needs to differentiate between compilers it tries to
determine what kind of compiler it is. In cctbx it's the other way
around - the --compiler flag tells what kind of compiler it is and the
build script guesses executable names. For ccp4 I added in two places
in libtbx/SConscript:
+    if libtbx.env.build_options.use_environment_flags:
+      if 'CC' in os.environ: cc = os.environ['CC']
+      if 'CXX' in os.environ: cxx = os.environ['CXX']
so for _some_ platform/compiler combinations it's possible to use
compilers with non-default names. Useful for systems with multiple GCC
versions.

- probe and reduce are called in mmtbx through phenix wrappers
(phenix.probe and phenix.reduce). We prefer to call them directly, but
I guess it's not to be changed in cctbx. But after changing the name I
also had to remove error checking in mmtbx/validation/clashscore.py
that checks return code from phenix.reduce. Reduce itself quite often
returns non-zero, it's just that the phenix.reduce wrapper ignores it
and always returns 0 (probably not intentionally).

- cctbx_project/spotfinder/SConscript - on Windows we have to link
dxtbxspotfinder with spotfinder. That's the only such problem when
compiling cctbx. OTOH it apparently works for everyone else. I don't
know why. It must have something to do with us using MinGW.

- A couple of #ifdefs for compiling with MinGW (annlib and gltbx)

Marcin