If opm-parser_ROOT is given, this should point to a build tree. The
only way to extract the corresponding source directory is to parse
the build cache located there.
Although CMake prefers the uppercase variant variables, and the
find_package_handle_standard_args will convert to them for us, the
part that parses REQUIRED and QUIET arguments to find_package still
only uses the package name verbatim (sic).
equals(ParserIntItem&) has a different signature than equals(ParserItem&),
thus the former method does *not* overload the latter. Virtual just means
then only means that you have created a *new* entry in the v-table. If
you call equals through a pointer/reference to the base class ParserItem,
the defined method in the derived class is not called, and we miss out the
test for the equal default value.
Instead, we should take an argument of the base type and use a dynamic
cast to the derived type. If this downcast fails, then they are not equal;
otherwise we have gotten ourselves a pointer to get the properly typed
default value.
We must use pointers instead of references; if we cast to a reference,
a bad_cast exception is thrown if the expression is not in the proper
type hierarchy.
It doesn't really matter here because "cjson" is only letters, but as
a general rule we define the uppercase variant ourselves so that CMake
doesn't use its own (bizarre) case rules, and then set the lower case
explicitly afterwards.
CMake will do some uppercasing of its own (defining OPM-PARSER_FOUND)
so it works best if we specify the correct uppercase version and sets
the lowercase afterwards.
The CMake script is run in the source tree. We assume a certain
directory layout and that the cjson is available in a sibling
directory of this project. Thus, we can pick up a build tree without
having the library installed.
The library will end up in the opm/json library in a build tree; we
want to be able to point the CJSON_ROOT variable to the root of the
build tree and have it pick up the libraries from there.
Surprisingly, some compilers (notably GCC 4.6.3) will issue a warning
when comparing a literal which is clearly positive to an unsigned type,
when looking for a suitable instantiation in Boost. This is fixed by
making the literal unsigned too, so there's no doubt.