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 serializations, 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 is on different hardware.
It is highly advised to subscribe to the CEREAL mailing lists. This allows notifications of the upcoming release of CEREAL, any performance improvements. It should be noted that we have already migrated to the new version, at least once.
Cereal is embedded into ecflow source code to avoid adding 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 provide 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 is 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 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 boost libs 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 installation 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 HTML 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 libs are installed on the system, the user has the choice not to use them. It should be noted that SSL enabled client/server carries a small performance penalty. It was added due to an external customer request, and it not used internally.