dlib
dlib copied to clipboard
davisking
Attempting to modernise the cmake build script
This PR requires CMake 3.17 or higher. Maybe this is too new. If anything, this is a good exercise in trying to understand cmake in more detail. The key points are:
- use the target_xxx() functions
- don't need variables for needed libraries, includes or sources. You can just use cmake functions to set things on targets
- use the built-in helpers for findings libraries like PNG, JPEG, GIF, SQLITE, even BLAS, LAPACK and CUDA It's not ready yet of course.
Getting there. I've opted for building everything in a single CMakeLists.txt file. So we have options DLIB_BUILD_TESTS, DLIB_BUILD_EXAMPLES and DLIB_BUILD_TOOLS, a bit like how other repos usually do things.
I realise this will never get merged, as I've substantially changed things but if anything, this is a good exercise in understanding cmake. Any feedback would be appreciated though.
Windows can't find fortran to build cblas from source. Need to figure out what to do about that
Yeah I don't have any good advice. Cmake 3.17 is totally too new though. We should target cmake versions that are installed by package managers of systems that are popular right now. 3.8 is about the right spot for the moment I think. Although I'm waiting for someone using RedHat or something to complain to me about even that :)
I'll get it working and see what I can do about getting down to older cmake version. At the moment this is more of a PoC to see how much we can simplify using modern cmake
Yeah I don't have any good advice. Cmake 3.17 is totally too new though. We should target cmake versions that are installed by package managers of systems that are popular right now. 3.8 is about the right spot for the moment I think. Although I'm waiting for someone using RedHat or something to complain to me about even that :)
Updating cmake is no bother. Just download the installer and run it, job done. Unlike a compiler, it's so easy to update. I reckon that should be the "workaround"
Yeah I know it's easy to install. People still don't though and would complain about it :|
Need to fix the setup tools stuff. Then I'll have a PoC. I'm liking the fact that most of it is vanilla cmake and everything fits in a monolithic CMakeLists.txt file under 800 lines including the library, tests, tools, python bindings and examples
If this doesn't make it into master, I think your fix for the latest Pybind11 should! I am reading this PR also to learn more about CMake :)
Warning: this issue has been inactive for 35 days and will be automatically closed on 2022-10-04 if there is no further activity.
If you are waiting for a response but haven't received one it's possible your question is somehow inappropriate. E.g. it is off topic, you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's official compilation instructions, dlib's API documentation, or a Google search.
I think all I needed to do was get the python tests to build in an easier way. Scikit-build seemed like a good candidate. But either way this all requires cmake 3.18 which I don't think is acceptable at the moment. We can always get this working and leave it open for a while until 3.18 becomes acceptable. Even if we decide this isn't a good PR it was a good cmake learning experience.
I think all I needed to do was get the python tests to build in an easier way. Scikit-build seemed like a good candidate. But either way this all requires cmake 3.18 which I don't think is acceptable at the moment. We can always get this working and leave it open for a while until 3.18 becomes acceptable. Even if we decide this isn't a good PR it was a good cmake learning experience.
Yeah, it's all good. Some day we will update to 3.18 :D
Here. Tagged this so it stays open forever (prevents the dlib bot from closing it). 3.18 is two years old. IDK, in a few years we can update :| I realize it's a long time, but it takes forever for cmake (and stuff like gcc) to filter into linux distributions a lot of people use. Like there are all these institutional users who run some version of redhat or whatever that's the "long term support" version. And they take like 5 or 6 years to get updated for tools like this.
I think what I'll do is write an intermediate cmake PR which works with 3.8
I think what I'll do is write an intermediate cmake PR which works with 3.8
I was playing with this last night. With minimal change, it's cmake 3.8 compatible.
I think what I'll do is write an intermediate cmake PR which works with 3.8
I was playing with this last night. With minimal change, it's cmake 3.8 compatible.
Nice :D
Why don't we put all the png, zlib and jpeg source code in the dlib namespace and always build that rather than having shared library dependencies ? It's C so it builds super quickly and won't impact users build times in any dramatic way. We could do the same for SQLite as well. That's only 2 files.
Why don't we put all the png, zlib and jpeg source code in the dlib namespace and always build that rather than having shared library dependencies ? It's C so it builds super quickly and won't impact users build times in any dramatic way. We could do the same for SQLite as well. That's only 2 files.
My guess: they will get outdated and have security issues, and we will need to keep updating them regularly in the repository (you can argue that we should already be doing that, though). I think this has already been discussed, right? https://github.com/davisking/dlib/pull/2410#issuecomment-893364810
And also, I'd rather use libjpeg-turbo instead of plain vanilla JPEG… Maybe I should try again to make it build on Windows…
Why don't we put all the png, zlib and jpeg source code in the dlib namespace and always build that rather than having shared library dependencies ? It's C so it builds super quickly and won't impact users build times in any dramatic way. We could do the same for SQLite as well. That's only 2 files.
My guess: they will get outdated and have security issues, and we will need to keep updating them regularly in the repository (you can argue that we should already be doing that, though). I think this has already been discussed, right? #2410 (comment)
And also, I'd rather use libjpeg-turbo instead of plain vanilla JPEG… Maybe I should try again to make it build on Windows…
Yeah, this is the reason. People really should use the versions of these libraries on their systems rather than the ones in dlib/external. They will in general be better, more updated, and all of that. Like your package manager can push a security update that updates the shared library for libpng and everything on the system is fixed automatically. That kind of thing is foiled by statically building everything together. These libs are only in dlib/external because lots of users don't know how to install other libraries on their systems. Or they use windows which makes using shared libraries super painful. Although dlib is in vcpkg and they will totally have set that up right, making libpng a separate thing (I mean, I'm assuming, I haven't looked but they must have done it right). It would be an additional pain on those package maintainers to make dlib depend specifically on the copies in dlib/external.