A very small release which makes the Python API work with latest Numpy again (fixing #72).

Minor updates for the MCPL_ENABLE_ZLIB=FETCH option for CMake, ensuring correct application of C defines as provided by the upstream zlib CMake code.

Another release with multiple CMake-configuration improvements. Most visibly, most high-level CMake options were renamed so their names are now prefixed with MCPL_ and use a more consistent naming scheme (#67). For example BUILD_EXAMPLES is now instead MCPL_ENABLE_EXAMPLES, find more variables by looking here. For now, it has been attempted to remain backwards compatible and support the old variables as well, but it is highly recommended to migrate to the new variables as soon as possible.

The dependency on ZLIB has been made more flexible. The new option MCPL_ENABLE_ZLIB is more flexible and supports one of several values: IFAVAILABLE, FETCH, USEPREINSTALLED, ALWAYS, OFF, or NEVER. The default value of IFAVAILABLE will try to locate ZLIB, but will simply disable ZLIB support if unsuccesful. The identical options OFF and NEVER are obviously simply disabling ZLIB support irrespective of presence on the system. The option ALWAYS will attempt to find ZLIB on the system, and if it fails it will instead fetch the zlib sources from the official zlib location at github, and build the appropriate capabilities right into the MCPL binaries. The option, USEPREINSTALLED is actually like the old default behaviour: look for ZLIB on the system and fail if it it is not available. Finally, the option FETCH will always fetch sources online, ignoring any ZLIB already present on the system.

A few other hidden expert-only options (MCPL_ENABLE_CPACK, MCPL_DISABLE_CXX) were added as well, supporting various integration and packaging efforts.

This is a very small release, which simply contains a few minor modifications to the main CMakeLists.txt file (for instance to fix #65).

This release provides a few improvements concerning configuration of downstream projects. First of all, it introduces a new command-line script, mcpl-config which can be used to query an MCPL installation for details, or even used to setup the user environment by typing
eval $(./path/to/mcpl/installation/bin/mcpl-config --setup) in a shell. Secondly, it modifies the installed location of CMake configuration files, to hopefully make it easier for downstream projects to locate an existing MCPL installation (more details on github issue #58). Finally, it modifies the manner in which Geant4 bindings must be activated in downstream CMake code. In short, previous usage of find_package(G4MCPL) should be replaced with find_package(MCPL COMPONENTS GEANT4BINDINGS ), and the target G4MCPL::g4mcpl is now named MCPL::g4mcpl.

Major update to CMake code, which first and foremost makes it possible for downstream CMake-based projects to use find_package( MCPL ) and through that get access to variables MCPL-related variables and build targets (i.e. the MCPL::mcpl target for projects needing to include the mcpl.h header file and link against the compiled MCPL library) (cf. github issue #58). Related to this the minimal CMake version is increased from CMake-3.0.0 to CMake-3.10.0. Another change is that Python scripts now refer to python3 rather than python (cf. github issue #55).

Users on ancient systems where any of these changes cause problems are simply recommended to stick with MCPL v1.3.2 for now, as they are otherwise functionally equivalent. Reports about issues not thought to be caused by outdated software are gratefully received as always at https://github.com/mctools/mcpl/issues.

• Fix time conversion bug in phits2mcpl and mcpl2phits, where ms<->ns factors had been mistakenly inverted (github issue #53). Thanks to @dddijulio (ESS) for reporting.
• Reorder link flags in documentation and "fat" Makefile to be correctly placed after the compilation objects. This fixes modern GCC compilation using as-needed flag, which is the default on Ubuntu (github issue #51).

• Python API now works with pathlib.Path objects from Python3.4 and later (github issue #50).
• Fix buggy array lengths in the Python block API on some files which were preventing pymcpltool --stats from always working (github issue #49).

• Introduce support for PHITS. This is done via mcpl2phits and phits2mcpl command line tools for conversions to and from PHITS binary dump files. Thanks to Douglas Di Julio (ESS) for help in adding this new feature.
• Introduce new --forcemerge option for the mcpltool and an associated mcpl_forcemerge_files function in the C API. This makes it possible to merge particles from otherwise incompatible files, at the heavy price of discarding descriptive metadata like comments and blobs. This is intended as a last-resort solution (github issue #43).
• Add new public function mcpl_transfer_last_read_particle, which makes it possible to perform non-lossy filtering or merging of files using custom C code (github issue #18).
• Fix pymcpltool --stats sum(weights) bug with python3 (github issue #46)
• Handle unexpected records at the end of SSW headers gracefully (github issue #45).

This small release brings support for MCNP version 6.2.