Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make build as subproject #82

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

stharward
Copy link

For QxOrm to build as a subproject, the definitions that libQxOrm is built with need to be propagated to the other targets that link against it. Otherwise you'll get "undefined reference" linker errors if the target has been built expecting a symbol that was disabled in the library. eg, if libQxOrm is build with -D_QX_NO_JSON and the target isn't, then the target won't link against the library.

@stharward
Copy link
Author

It looks like the cmake build system as a whole could use some streamlining and updating. It doesn't really play well with how current cmake-based projects expect a library to behave. Like, it should be possible to just find_package(QxOrm) and target_link_libraries(MyProject PUBLIC QxOrm) and that's it.

Are you open to updating the cmake process? If so, I'll put those changes together into another PR.

@QxOrm
Copy link
Owner

QxOrm commented Dec 9, 2022

Hello,
Yes cmake integration with QxOrm library is not perfect :)
I see that you have added some target_compile_definitions calls with the PUBLIC keyword.
I need to test it a bit on all my environments (Windows, Linux, MacOS, several versions of Qt) : if everything is fine, I will integrate your patch : thank you !

@stharward
Copy link
Author

stharward commented Dec 9, 2022

Yes cmake integration with QxOrm library is not perfect :)

I started looking at what would be needed to bring the cmake buildsystem up to current best practices. As far as code goes, I think the only changes needed are to add #include "moc_filename.cpp" lines at the bottom of the few .cpp files that implement classes depending on QObject. There may be a few other cryptic compile-time bugs that need to get fixed along the way.

I can overhaul the CMake build system, but I'm not sure I can do it while also keeping the qmake system intact. qmake's effectively dead upstream. It's unnecessary to build Qt5 projects, entirely gone from Qt6. Are you okay with giving up qmake for building QxOrm?

@QxOrm
Copy link
Owner

QxOrm commented Dec 12, 2022

Are you okay with giving up qmake for building QxOrm?

For now no, I would like to keep qmake because I'm pretty sure some customers still use it.

@stharward
Copy link
Author

Are you okay with giving up qmake for building QxOrm?

For now no, I would like to keep qmake because I'm pretty sure some customers still use it.

Okay, I will do as much as I can without affecting qmake builds. Though even if there are customers that are using qmake in their own builds (like a program that still uses Qt4), they can use cmake to build QxOrm and use qmake for their own program.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants