Closed SSoelvsten closed 2 years ago
Indeed we haven't really done anything with the CI setup for multiple years. I think switching to GitHub actions would be fine.
As for the GCC version, I think Ubuntu 16.04 is on GCC 5.4, which is probably why GCC 5 was targeted when we set up CI in 2015-2018. TPIE doesn't have a formal compiler version policy but I think GCC 7 (which is used in Ubuntu 18.04) is a fine target.
As for compilers on Mac and Windows, I think we should bump to new-ish versions and see if we can make it work, but I don't have a lot of experience personally with compiling TPIE on non-Linux platforms.
test_pipelining_runtime.cpp
If this file includes another "cpp" file, that seems bogus and is something we should just try to fix. E.g. ensure that whatever symbols in "runtime.cpp" that are needed in the test are not in an unnamed namespace, and then copy some declarations into "test_pipelining_runtime.cpp" to make it work.
Alternatively put the declarations into "runtime.h" under an #ifdef TPIE_PIPELINING_RUNTIME_PRIVATE
or something like that, and #define
that before including the header in "runtime.cpp" and "test_pipelining_runtime.cpp".
It has not shown up when porting the CI jobs to GitHub Actions, so I have not followed up on it.
Looking at the output of Travis CI the continuous integration suite has been left unmaintained.
Linux tests:
GCC 5 does not work, since
std::uncaught_exceptions
in runtime.cpp was first added with GCC 6. Since this problem has lingered for a long time, I assume noone cares about GCC 5 support anymore? Furthermore, a quick search still shows that the deprecated (and per C++20 removed)std::uncaught_exception
still lingers in some places.GCC 7 tests in test_pipelining_runtime.cpp do not work, since importing
tpie/pipelining/runtime.h
andtpie/pipelining/runtime.cpp
result in linking issues with functions defined twice.MacOS tests:
brew update; brew install snappy lz4 zstd
fails on installing zstd.Windows:
I would gladly offer to get it back up to speed and fix the above mentioned issues. This project does currently use Travis CI whereas my main experience is with GitHub Actions. The easiest way for me to resolve this would be to port everything to GitHub actions, since I can then test everything before I send in the pull request. Assuming you need to keep using Travis CI it would take me a bit longer, but I would still offer this help. What would you prefer?