Tester develop #780
Tester develop #780
Conversation
- std::uncaught_exception is now defined. - Compiler options are separate strings and do not need escaping.
swatanabe-b1
force-pushed
the
tester-develop
branch
from
b4b22da to
6047153
Compare
Boost.Test only works in header only mode for now. Building it as a static library results in mysterious link errors. Support stdio/iostreams in CDT (only works in the tester, not in contracts as EOSIO has neither a filesystem nor stdin.) Eliminate file handling and generic test library functionality from tester.
…global) database API more error prone.
Instead of using std::variant, use a custom type that serializes like variant, but directly exposes the latest version of the type. Only one type is supported for now. Handling more than one type would require the ability to convert from old formats.
- Remove unused get - Use EOSIO_REFLECT instead of EOSLIB_SERIALIZE
…und and used by to_bin and from_bin.
There was a problem hiding this comment.
Please remove the boost additions, for cdt we've been actively moving away from boost and I don't want to further the reliance on it. Second, you changed the header relative pathing, I would like that to go back to the way that it was. Relative paths allows CDT to block off automatic inclusion given different compilation contexts, second it ensures that only the header files we expect are the ones that are used.
|
I moved away from relative paths so that it could find the abieos headers. |
I would still like the relative includes. It saves a lot of headache if multiple places are in it's include path that could have the header files. Secondly, we should be installing the abieos headers in a specific location, that is in the CDT include path. |
It only saves headaches by papering over the underlying problem. When building CDT, we control the include paths, so it shouldn't be an issue. We also control the default include paths of the compiler, so it can only affect users who add their own includes. If they add an include path that conflicts, then it's a toss-up whether forcing use of our own headers will fix the problem or make things worse. |
|
It’s not papering over a problem. It’s a library, it’s just good hygiene for one. Secondly, CDT doesn’t control things like eos installs. Which historically have installed to weird locations and has caused problems (so did cdt pre-1.2 (pre packages), I am not without blame in this too). |
No it isn't. Your argument is somewhat valid for internal headers, but these headers are not internal. A library's public headers must have globally unique names that do not conflict with anything else in the user's include path. As long as this holds, <> includes are guaranteed to be safe. If this does not hold, then it isn't only CDT that's broken. Users' code is also directly broken.
It shouldn't matter where eos is installed. |
|
I don't think you get what I am stating. If I include in my code |
|
I understand exactly what you're saying and I disagree. The scenario that you've described is problematic regardless of how CDT handles its includes, because users can also #include <eosio/foo.hpp> and this will be equally broken. In fact, it will be even more broken, because it will cause two different versions of eosio/foo.hpp to be included in the same translation unit. |
|
Can this PR be closed since tester is now in eos? EOSIO/eos#9018 |
|
The wasm side is still in CDT, but this PR is really out-dated by now. |
Agreed, I think it would be more valuable to open a new one with just the parts that we need in CDT. |
Change Description
Ports #674 to current eosio develop. Also works with release/2.0.x. Does not compile with release/1.8.x because of differences in chainlib.
API Changes
Documentation Additions