I have refactored a few classes in the http_client module and brought the CMake build directory in an inconsistent state with the install directory. That is, running any query using the http-client module I got this error:
zerr::ZXQP0028_TARGET_NAMESPACE_NOT_PROVIDED. And this without changing the module URI.
This look like a problem in the cmake build system around the modules (in this case only internal ones) and the loading of those form the install/build directories.
To solve this I had to delete from the build directory:
- zorba_modules/zorba_http-client_module
- modules
and the install directory
To replicate this, try:
- build from lp:~gabipetrovay/zorba/cpp-xml-parsing rev. 10490
- (n)make install
- run a query from install directory and make sure that it runs (at r.10490 you will get a segmentation fault but that is another problem and a sign that it find the module)
- update to rev. 10491
- run cmake and build again
- (n)make install
- now running the query again you should get: zerr::ZXQP0028_TARGET_NAMESPACE_NOT_PROVIDED
- deleting the directories above will solve the problem
This happens because DECLARE_ ZORBA_MODULE( ) uses a glob pattern to find all .cpp files in the module's source directory. When you make a change which adds new .cpp files, as you did here, it's unfortunately necessary to re-run CMake. There's no way CMake can detect this change automatically, so it doesn't build the new files. I tried doing your experiment and was able to reproduce the bug (it actually gave a runtime linking error after updating to r10491, but I'll put that down to an OS difference). Then I tried it again but adding a call to "cmake" after updating to r10491, and the query ran fine.
CMake recommends against using glob patterns for naming source files for exactly this reason, but I couldn't think of any other way to make a general-purpose DECLARE_ ZORBA_MODULE( ) macro. I suppose it could take a list of source files rather than doing a glob pattern... hard to know whether this would be an ease-of-use improvement or not. What I certainly will do, though, is update the documentation to indicate this problem, and to instruct users to re-run CMake after adding any new .cpp files.