Currently, we provide C-oriented functions in libcbxp.a. Maybe we could provide C++ specific interfaces for C++ callers where string parameters can be provided as std::string parameters and nlohmann::json objects can be returned, with errors being handled with exception handling? In that case, we would have to provide a copy of the nlohmann/json.hpp header, which should be okay since we already provide a license notice. The MIT license makes no distinction between distributing the compiled code or source code. The main thing might be setting up the include directory to have a cbxp/nlohmann sub-directory, just to make it clear that nlohmann/json.hpp is shipped as part of CBXP since the header does not have cbxp in its name and is technically part of a different open source project getting redistributed in our project. If we don't do this, it can cause confusion and even conflicts with the symbolic links created in zopen installations.
I see that ncurses provided a libcurses.a and libcurses++.a static library implying that one is C++ specific. In our case, I don't know if it is necessary to have a separate library though since the same library should work for both C and C++ callers. We may need/want a C++ specific header, but the same static library should be able to be used.
Currently, we provide C-oriented functions in
libcbxp.a. Maybe we could provide C++ specific interfaces for C++ callers where string parameters can be provided asstd::stringparameters andnlohmann::jsonobjects can be returned, with errors being handled with exception handling? In that case, we would have to provide a copy of thenlohmann/json.hppheader, which should be okay since we already provide a license notice. The MIT license makes no distinction between distributing the compiled code or source code. The main thing might be setting up theincludedirectory to have acbxp/nlohmannsub-directory, just to make it clear thatnlohmann/json.hppis shipped as part of CBXP since the header does not havecbxpin its name and is technically part of a different open source project getting redistributed in our project. If we don't do this, it can cause confusion and even conflicts with the symbolic links created in zopen installations.I see that ncurses provided a
libcurses.aandlibcurses++.astatic library implying that one is C++ specific. In our case, I don't know if it is necessary to have a separate library though since the same library should work for both C and C++ callers. We may need/want a C++ specific header, but the same static library should be able to be used.