adapt cmake find for dl-library and sqlite3-library

[AHeimberger]

Hey, thanks for this 'database access layer'. I would like to use it within an embedded linux project, but currently face a build error due to yocto and the rm_work bb-class. Whenever I try to build the provided open-embedded recipe the build fails because it looks up for the libdl.a and libsqlite3.so in the sysroot directory of soci. To fix this I looked up the current cmake implementation and came up with the two commits.

It is still a Work in Progress: I have problems identifying how to make the CI and the Yocto-Project passing the build. find_package(SQLite3) uses the delivered Module from the directory which has preferred paths for the CI and I have not found a way to disable CMAKE_MODULE_PATH specifically for this SQLite3 module.

[AHeimberger]

I tried different ideas to make libsqlite3.so available for the ci and yocto builds

• disabling the provided FindSQLite3.cmake file with an option
• extending PATHS within FindSQLite3.cmake by extending it with CMAKE_SYSROOT.

However, the only way I got it to work was by disabling the complete CMAKE_MODULE_PATH in the root CMakeLists.txt file.

[vadz]

Sorry, I don't really understand neither the original problem nor the solution.

Do you mean that something references the files created during SOCI build in its build directory after it was deleted? If so, isn't the solution just to install SOCI in some directory which doesn't get deleted? I could be completely missing the point, of course, but please explain what actually happens if I do.

[AHeimberger]

I do not know if you know yocto. So what I actually try to do is building a custom embedded linux which has an application that uses soci to access a sqlite3 library. To build it locally I use a class which is called rm_work. That class is used to remove the temporary workspace (wanted e.g. if size of hard-disk is not so big, or just to avoid a huge amount of files).

Within that yocto project I have multiple recipes, each recipe is processed and creates a temporary workspace. When i use that soci recipe the database access library will be created. Next I will use a custom recipe which depends on soci. So the custom recipe takes all the required files from that temporary workspace and removes the soci workspace. Due to the fact that there is a custom cmake module to find the library dl and sqlite3 there are absolute paths within the build-files, and now the build of the custom recipe fails. The path to the libraries does not exist anymore because it points to the temporary workspace, but the libraries are already within the temporary workspace of the custom recipe.

Therefore I provided 2 commits:

• The first commit uses CMAKE_DL_LIBS within target_link_libraries, instead of the custom written find_package which I removed.
• The second commit allows to disable adding additional cmake module paths to the CMAKE_MODULE_PATH. By disabling the custom module I am able to use the default provided from cmake FindSQLite3 / Source.

However I am not allowed to remove the custom written FindSQLite3 module completely, because it contains paths which are defined in the CI install. If I remove it the CI would fail.

[vadz]

I know of yocto but I've never really used it.

Anyhow, thanks for the explanation, but I still don't understand why do the paths for the dependent libraries become invalid. These libraries should be out side of the temporary workspace normally, shouldn't they?

It's probably a good idea to use CMAKE_DL_LIBS (although I'd appreciate any confirmation from CMake experts), but how does the standard FindSQLite3 module differ from the one included in SOCI and what exactly results in the problem occurring with the latter but not the former?

[AHeimberger]

It is just a guessing right now. In the past there was an option called LIBDIR / SOCI_LIBDIR. This option has been removed in commit https://github.com/SOCI/soci/commit/d8632f5aca9042bc5788b462b7fdee14b97ae5be but is still referenced in the old .bb-recipe. Momentary I am not sure if they solved it this way.

The main difference between the two find_package implementations soci vs. cmake is I guess the Hint to the paths.

I need a bit more time and I will also try to deliver something so you can reproduce it on your own. BR

[vadz]

Sorry, I'm not going to apply this in its current state, so closing.