In our downstream project, we have two dependencies: solidity and spdlog.
Both of them depend on fmtlib. Unfortunately, the versions of fmtlib they
use do not match, which leads to compilation failure.
The issue arises because spdlog attempts to use solidity's fmtlib, but the
specific version (v8.0.1) has a bug. Ref: https://github.com/gabime/spdlog/issues/2142
While we could keep this change in our own fork, we believe it would
be worthwhile to contribute it back to the upstream since spdlog is a
very popular logging library.
Signed-off-by: Jun Zhang <jun@junz.org>
Similiar to CMAKE_SOURCE_DIR. Using CMAKE_BINARY_DIR will put the
generated header (stdlib.h) in build/include/solidity/libstdlib but it
should start with build/third-party/solidity or the library can't find
the header.
Signed-off-by: Jun Zhang <jun@junz.org>
When using solidity as a third-party library (include it into our
project using FetchContent), we encountered a strange compilation error.
For some reason, cmake considers the root directory of the project as
the root directory of the dependency (solidity). This is because
solidity is incorrectly using CMAKE_SOURCE_DIR variable, which should be
PROJECT_SOURCE_DIR (The former one refers to the top-level source
directory that contains a CMakeLists.txt, while the latter refers to the
source directory of the most recent project() command)
I've created a repo for demonstration (https://github.com/junaire/test-solidity-fetch-content)
Signed-off-by: Jun Zhang <jun@junz.org>
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
