Revamp CMake support

[Krzmbrzl]

Fixes #1115
Fixes #1152
Fixes #1122
Fixes #1094
Fixes #1159
Fixes #644
Fixes #1005
Fixes #1111
Fixes #1015
Fixes #929
Fixes #843
Fixes #456
Fixes #394
Fixes #208

[vadz]

Do you think we should wait for this before making SOCI 4.1.0 release or can we leave this change until a later 4.1.x?

[Krzmbrzl]

Do you think we should wait for this before making SOCI 4.1.0 release or can we leave this change until a later 4.1.x?

Well, it would probably be nice if 4.1 had this already, but it's more of a nice-to-have. So I guess you don't have to wait for this PR to be done.
However, my planned timeline for this PR is to get this finished within the next two to three weeks. Depending on your plans for 4.1, waiting for such a time period would be okay? But as I said: it's optional.

---

Unrelated to this PR, I would appreciate if #992 made it into 4.1 though :)

[vadz]

Thanks for the feedback! With regards to the MySQL situation I have checked on my system again and indeed PkgConfig reports -I/usr/include/mysql as well. Using -I/usr/include with #include <mysql/mysql.h> just happened to work by chance. I have revised the corresponding Find module and dropped the SOCI_MYSQL_DIRECT_INCLUDE dance entirely as the find module should now always pick the correct include path 👀

Great, thanks!

I'd like to revert this because there seems to be no need to break the previously working builds using the existing variable name

I don't revert the change as the way it works now is the canonical way how things work in most other CMake find modules. However, I have added a compatibility layer that will automatically translate between the old FIREBIRD_INCLUDE_DIR and the new Firebird_INCLUDE_DIRS so old builds should remain functional.

OK, this works too, thanks.

I have a couple of scripts I use for running the tests for all the backends

I'd recommend simply using ctest for this purpose (potentially with the -R option to restrict to a specific subset). That way you are independent from any specific names of the executables.

Thanks, this is probably a good advice, but I don't always CMake for building and I also suspect that I might be not the only one doing it like this, so it's still nice to avoid unnecessary changes.

To my knowledge I am up-to-date again in terms of addressing review comments. Let me know if I missed something!

I'll try to retest a.s.a.p., thanks again for your work!

Finally, I have taken the liberty of adding a commit that updates the used FreeBSD version during CI to 14.2 as the 14.0 image is no longer available and therefore leads to the CI failing. If you prefer of doing this separately, I can simply remove that commit again but I was hoping that this PR gets merged soon-ish anyway and therefore it shouldn't matter.

Yes, it doesn't really matter and I do hope to merge it soon.

[vadz]

Sorry, I still have a problem with MySQL on my system. Configuring says

-- Found MySQL: -L/usr/lib/x86_64-linux-gnu/ -lmariadb (found version "10.11.6")

but I get an error about mysql.h when building and the compiler command line is wrong: it contains

-isystem "$srcdir/src/backends/mysql/-I/usr/include/mariadb -I/usr/include/mariadb/mysql"

(where $srcdir is the full path to SOCI checkout directory) i.e. there is a missing space before the -I and I have no idea what's going on here: -isystem should be coming from

  target_include_directories(MySQL SYSTEM INTERFACE ${MySQL_INCLUDE_DIRS})

in cmake/find_modules/FindMySQL.cmake, but MySQL_INCLUDE_DIRS has correct value there (verified by adding a message() showing it).

Any idea what's going on here?

[vadz]

@Krzmbrzl I do appreciate your efforts to find this problem, but perhaps it would be better to run the debugging CI jobs in a separate branch in your own fork?

[Krzmbrzl]

Why? I don't see a big difference in whether the CI runs on the PR branch or on a different one 🤔

Anyway, the I am done and the issue is resolved (at least in the CI setup).

[vadz]

Why? I don't see a big difference in whether the CI runs on the PR branch or on a different one 🤔

Mostly to avoid a lot of force pushes here, which result in confusing notification emails being sent. When I need to do something like this, I usually start by creating a branch in my fork and disabling all the other CI jobs in it to avoid running them uselessly, then just cherry pick the commit with the fix to the real branch.

Anyway, the I am done and the issue is resolved (at least in the CI setup).

Thanks, I see what you did, but isn't it a bit dangerous to strip anything of the form -\w here? I'd restrict it to just -I for the includes and -l for the libraries. But we can have -L options in pkg-config output too... Unless CMake provides some way of separating them, perhaps we should just add them to target_compile_options and target_link_options instead of using target_include_directories and target_link_libraries?

[vadz]

Actually, sorry, I still don't understand what is going here :-( According to CMake docs we should have

<XXX>_INCLUDE_DIRS

    the '-I' preprocessor flags (without the '-I')

<XXX>_LIBRARIES

    only the libraries (without the '-l')

So why do we need to remove the -Is and -ls?

[vadz]

OK, to answer my own question, this is because we don't use pkg-config at all in this case, as we don't ever ask for libmariadb, only mysqlclient. This is not intentional, isn't it?

And we should do this replacement only in case when we use mysql_config or mariadb_config, not always, as now. This would also fix

    if (EXISTS "${VERSION_FILE}")

test which should be always failing for mariadb currently.

Should I push a fix for this into this branch?

[vadz]

Sorry, I'm finally pushing my changes here without waiting for the answer as applying the regex replacement unconditionally broke Windows build, as can be seen here and I think my fixes should help with it.