STD
ecflow uses many parts of std library. Originally ecflow used boost::shared_ptr, however for ecflow 5, this was replaced with the equivalent std::shared_ptr.
This was also required because of Cereal.
Std::auto_ptr has been replaced with std::unique_ptr, boost::regex has been replaced with std::regex.
CEREAL
Is used to provide the client/server serialisations, and uses JSON text. There was an option to use BINARY which is a lot faster. But then we lose the backward compatibility, and more importantly the client/server communication may break due to byte order incompatibility. i.e when client/server are on different hardware.
It highly advisable to subscribe to the CEREAL mailing lists. This allows notifications of upcoming release of CEREAL, any performance improvements. It should be noted that we have already migrated to new version, at least once.
Cereal is embedded into ecflow source code to avoid another dependency.
Currently the latest intel compiler breaks with CEREAL. for more details see: ECFLOW-1600
The web page is at: https://uscilab.github.io/cereal/
BOOST
ecflow uses many parts of the boost libs.
- program options, provides the command line options for both client and server, in addition also provides the command line help.
- asio : this provides the client/server communication protocol. based on TCP/IP and uses JSON(via CEREAL).
- python. boost python provides the ecflow python API. The API is documented with SPHINX.
- file system: use for all file and directory access.
- date and time: this is used in all the time base attributes and calendars
- chrono: used for test timing.
- test: used to provide unit tests, and client/server and python tests. There are several hundred tests for client/server/python, however there are no test for the GUI.
- spirit classic: this is used to provide the trigger expression parsing. This library is now legacy, and needs to be replaced with later boost libs.
It should be noted the boost build(based on bjam) is still used occasionally. But has been replaced with CMAKE. however, on some systems where we are not allowed to install any packages, it can be still be used to install ecflow client/server/python libs. Only the GUI integration is missing.
Many of boost lib can be replaced with std equivalents over time. This has already been done with shared_ptrs. With C++17, we can additionally, replace:
- boost::filesystem with std::filesystem. For more details see: https://www.bfilipek.com/2019/05/boost-to-stdfs.html
- boost::stringview can be replaced with std::string view.
Other possible use that were planned but not used, were boost exception. This would automatically add function, line number, etc. At the moment this is done manually.
Boost build
Boost build is required to build/install the c++ boost libraries. At ECMWF boost is built/installed with metabuilder/master branch.
To build/test ecflow with a new boost version without installing can also be done. Please use build_scripts/boost_build.sh. This can also be used to test install before going to the metabuilder.
At some point in the future we can drop the python2 support. This require some minor modifications to build_scripts/boost_build.sh and metabuilder/settings/boost
It should be noted that to debug and build the boost libs does require some familiarity with boost bjam
Doxygen
Ecflow provides support for doxygen generated documentation via integration with cmake. The main benefit here is to see the class hierarchy.
To generate the doxygen, change directory to the cmake build dir.
make doxygen Then open in the browser: <builder_dir>/Doc/doxygen/html/index.html
SPHINX
At one point all of ecflow documentation was done with sphinx, however when confluence was adopted, we were asked to stop using it.
The ecflow python API documentation is still provided by SPHINX. However to get documentation into confluence requires some massaging. This conversion was provided by user support.
SSL
Ecflow uses SSL for encrypted communication between the client and server. The cmake build will only use SLL when openssl libs are available on the system. Even when these lib are installed on the system, the user has choice not to use them. It should be noted that SSL enabled client/server carries a small performance penalty. It was added due to external customer request, and it not used internally.