Revamp CMake support #1118
Revamp CMake support #1118
Conversation
|
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. Unrelated to this PR, I would appreciate if #992 made it into 4.1 though :) |
Krzmbrzl
force-pushed
the
revamp-cmake
branch
from
7815446 to
c8d5da6
Compare
Krzmbrzl
force-pushed
the
revamp-cmake
branch
7 times, most recently
from
0b83bb8 to
e1e4433
Compare
Krzmbrzl
force-pushed
the
revamp-cmake
branch
18 times, most recently
from
e4b2e0d to
39b9037
Compare
|
@vadz Now that I finally worked around the VS2015 bug, I think this PR is ready for review @papoteur-mga I'd appreciate your continued feedback on this too :) |
There was a problem hiding this comment.
Thanks again for all your work on this!
Unfortunately I ran out of time for today at 77/104 files viewed, I'll try to finish this a.s.a.p. but I'd like to already publish the existing comments/questions to see what do you think about them.
I'd also like to mention that I had seen in some discussions that you were not sure which directory structure to use for the installation. IMO the answer to this is always "the same one as now for compatibility unless there are some really good reasons to change it", so I hope we're not going to change things if we can avoid it. In fact, if we could avoid all these renamings even internally, it would be nice too, but, of course, it's the externally visible file locations, targets, option values etc that are the most important.
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| lib_type: [shared, static] |
There was a problem hiding this comment.
This doubles the number of builds and I'm not sure if it's worth it... Maybe it would be enough to test just some static builds instead of testing all of them?
There was a problem hiding this comment.
Compared to the Windows CI these are really cheap to do. Besides, previously SOCI did this duplication anyway due to building shared and static libraries in a single build. So effectively, this is reproducing the original behavior (plus some extra overhead of these things now actually being different build jobs).
Finally, it is a bit of a hassle to specify that only some combinations shall be built as a static library in GitHub Action syntax. Therefore, I would tend to just keep all tests 👀
| # Linking with just soci_core is enough when using shared libraries, as the | ||
| # required backends will be loaded dynamically during run-time, but when using | ||
| # static libraries you would need to link with all the soci_<backend> libraries | ||
| # needed too. |
There was a problem hiding this comment.
I would probably also keep this part of the comment too, especially if it's still correct (is it?) and just mention that SOCI::soci links with everything.
There was a problem hiding this comment.
I don't want to encourage people to use different linking strategies depending on whether they want to use SOCI as a shared or static library when the way that works for static lib works just as well for the dynamic case.
This will only cause confusion if people set up their project to use SOCI as a shared library and then at some point switch to static SOCI, just to run into a bunch of errors even though for the dynamic library everything worked as expected.
There was a problem hiding this comment.
I don't think the comment would be correct--for example, on Windows you have to link against the import libraries anyways, so static and shared linking via CMake targets should be one and the same. E.g. if I want to use the ODBC backend, I'll use target_link_libraries(my_target PRIVATE SOCI::soci_core SOCI::soci_odbc) anyways.
So yeah, if it makes sense to remove it, removing it is probably the way to go.
|
|
||
| add_library(soci_db2 | ||
| ${SOCI_LIB_TYPE} | ||
| "blob.cpp" |
There was a problem hiding this comment.
Inconsistent indentation and why do we quote all these file names? This makes them less readable and doesn't bring anything, it's not like we're ever going to have spaces in the source file names (or at least only over my dead body).
There was a problem hiding this comment.
I consider it good practice to quote filenames as they can (in general) contain spaces and I dislike having only selected ones being quoted. But if you have a strong opinion on this, I can remove the quotes.
|
I'd really like to refactor the tests to avoid having to recompile the entirety of Not sure if I should wait for it to be merged or should make these changes and resolve the conflicts later. |
|
So effectively you want to do the refactoring that I have already done here? 👀 Personally, I would tend to not create the same change in a different PR while we are already working on getting this PR merged 🤷 |
|
Yes, I'd like to apply this part (which is, again, something I really wanted to do since a long time, so thanks for finally doing it), except
Would it be possible to do this somehow? |
Which inconveniences?
I guess, but it would be a bit fiddly. Not sure if I personally see the value in having this part of the change a bit earlier given that the current approach has been used for so long (so my question here is: why the sudden hurry?) 🤷 |
Renaming the file complicates its history (even if Git is much better at this than many other VCS). And the real question is anyhow not "why not do it" but "why do it", i.e. do we have any good reason for renaming these files? And I just don't see any, both
No particular hurry, but I'm thinking about this every time I have to modify the tests and I plan on doing this again soon, so I thought it would be nice to finally get it done. |
Krzmbrzl
force-pushed
the
revamp-cmake
branch
2 times, most recently
from
227e55b to
be77273
Compare
Fixes #1115
Fixes #1152
Fixes #1122
Fixes #1094
Fixes #1159
Fixes #644