Hacker News Reader

Comment by fouronnes3 | Hacker News Reader

CMake is by far the worst language I have ever worked in.

Oh thank god, this thread is making me feel much better about myself.

I've been trying to integrate OpenCV's C++ library with my own C++ code (not involving Python), with the additional contrib modules (meaning I have to compile OpenCV myself), for multiple platforms, and I got stuck on CMake for so long it made me question if I was just a total idiot and should give up on programming forever.

to give another data point: I was given a project a couple weeks ago that was using visual studio solutions and opencv + contrib modules - I fighted 3 hours with making the .vcxprojs work on my machine before porting the whole shit to cmake in 15 minutes.

Using OpenCV was just a matter of

    find_package(OpenCV 3.3.1 REQUIRED)
    target_include_directories(theApp PUBLIC ${OpenCV_INCLUDE_DIRS})    
    target_link_libraries(theApp PUBLIC ${OpenCV_LIBS})

and everything worked, so I'm curious about what failed for you

plus 1 for this, I have been using CMake with my students for a year (moving from qmake) and this in conjunction with vcpkg to install stuff has been a breeze. This book is great too https://crascit.com/professional-cmake/

Thanks for your reply.

Will this include the contrib modules even for Android? And iOS?

Once I sat down and read the Cmake basics, yes, it was easy enough to get OpenCV working with basicallly the code you posted, except I couldn't find a way to include the contrib modules in an Android version, it would always complain Aruco wasn't there.

Until I went and compiled OpenCV myself, and that was the part that was a massive pain in my ass - CMake failing to include architecture information in the library files unless you specify it on the command line before running Cmake GUI, even tho it is an option in the GUI. Tho perhaps that's more of a failing of the OpenCV build script than Cmake itself?

I did just recompile OpenCV myself, so I did get there in the end and it's all working now, but I'm sure I'll be tweaking all parts of this project for months to come so if there's an easier/proper way, I'm happy to learn.

It also needs to be statically linked.

Note: I'm not a real programmer, I don't know enough to have even been able to get an entry level job in the industry yet, I'm an idiot that doesn't belong on this website. I'm just trying to learn as I go.

Humility is good, but it's important to acknowledge that CMake very often feels awful. I consider myself a competent developer and it's still pulling teeth trying to get what I want out of it.

Some things will get easier with time, and a lot of other things are going to suck shit forever. Keep on truckin'!

> Humility is good, but it's important to acknowledge that CMake very often feels awful.

Those times coincide with projects that fail to follow the "modern Cmake" style, based on build targets instead of pretending Cmake is a scripting language.

Keep in mind that modern Cmake style is a thing since the release of Cmake 3.0, which was what? A decade ago?

If developers who don't know better end up writing messy unmaintainable code, their code is an unmaintainable mess. That's not a result of their tech stack, but their own work.

Thanks!

To be honest I think alot of my frustration was with the OpenCV build scripts rather than Cmake itself, but I don't love Cmake either.

> Once I sat down and read the Cmake basics, yes, it was easy enough to get OpenCV working with basically the code you posted, except I couldn't find a way to include the contrib modules in an Android version, it would always complain Aruco wasn't there.

If this worked on desktop, I would assume this to be a bug in the OpenCV cmake files, there's no reason for aruco not to be in OpenCV_libs if my understanding of the OpenCV build system is correct (but then I did not really have to fight it)

You may be correct. The way I understand it, those extra libs are only there in the desktop versions, not mobile, but it's definitely possible I misunderstood.

Still, even tho it was frustrating and felt like a waste of time, learning to compile a big project like OpenCV taught me alot, and all or part of that will probably be useful in the future anyway :) even as a dot point on a resumé

It improved my shell scripting skills, and helped me understand how C++ links, and what library files actually contain etcetera

Whether cmake is good or bad, and whether it was necessary for my project or not, now I have successfully used Cmake to compile a big library!

I have to statically link it anyway, so compiling OpenCV separately and manually allows me to cut it down and make build changes etc that might be useful, as well as forces me to look at how it's structured and understand it better.

Thanks for your help!

> Tho perhaps that's more of a failing of the OpenCV build script than Cmake itself?

That is exactly what that is. Cmake is extremely powerful, and it lets library authors make build configuration that is quite often too flexible. Combine that with no standardized package manager for c or c++ for decades, and much cmake evolution over that time, means you encounter many different ways to solve problems.

Opencv is up there for most complex cmake projects. Only behemoths like VTK, ITK, and ROS beat it in complexity of the build.

Also, don't beat yourself up too much. :)

Speaking as the author of the post, I completely agree! I got burned so many times by random shit that made no sense. Stringly typed languages are the absolute worst.

Agreed. I will never understand how a group looked at overly-complex Makefiles, determined it was hard to write complex build scripts, and concluded: "I should write a Makefile meta-language that can generate these." That would be like looking at a complex Java codebase and concluding that the best solution to simplify it would be to write a Java meta-language for generating your classes...

If you only ever generate makefiles with cmake, then you probably don't need cmake.

I'll tell you exactly how: trying to maintain cross platform ITK builds on tons of bespoke HPC clusters and academic workstations using the existing build tools became a nightmare.

Writing makefiles is extremely repetitive and tedious and error prone: precisely the kind of thing to automate. Not just makefiles mind you, cmake is designed to automate all sorts of build parameters.

I bet you never tried to write large scale Makefiles across several OSes, even POSIX ones.

> I will never understand how a group looked at overly-complex Makefiles, determined it was hard to write complex build scripts, and concluded: "I should write a Makefile meta-language that can generate these."

If that's your personal experience then it seems you do not have any relevant experience at all developing and maintaining software projects, specially if they need to be cross-platform and cross-tech stack.

For example, it's clear to anyone with any basic experience that providing an abstraction over C++ compiler's so that you can ensure your C++ project can and does build successfully regardless of C++ standard, compiler make and model, and eve os and os distribution is extremely valuable.

Can you show me a Makefile that handles that?

With Cmake you get the exact same C++ project building flawlessly on macOS with Xcode and clang, windows with any version of MS Visual Studio, and of course any linux distribution.

You just download the project, run Cmake to generate a makefile, and build

How do you expect to even run a Makefile the same on all those combinations?

There are very good reasons why Cmake is the de facto standard.

I think modern cmake mostly has the right ideas, but the overall implementation is poor, mainly due to legacy.

> I think modern cmake mostly has the right ideas, but the overall implementation is poor, mainly due to legacy.

I fail to see how cmake's take on build targets is "poor". Can you provide an example that helps explain your point of view?

Reply on news.ycombinator.com