Doesn’t North Koreans fighting in Ukraine mean that North Korea now is at war with Ukraine? Wouldn’t that legitimize a Ukrainian invasion of North Korea? Could we ship some Ukrainians to North Korea and have them do a lot of damage there; including offer asylums to anyone who wants to get out?

After checking that you can open port 53 udp yourself with, say, nc (which you tried), strace the binary that tries to open port 53 and fails, and find the system call that fails. You can compare it with an strace on nc to see how it differs.

If this doesn’t clue you in (e.g., you see two attempts to listen to the same port…) Next step would be to find in the source code where it fails (look for the error message printout) and start adding diagnostic printouts before the failing system call and compile and run your edited version.

Especially if the media is readily available elsewhere which is always the case for movies you “bought” digitally.

Except when they aren’t. Especially if located outside the US, it is far from obvious that a given movie is available through another service.

Refunding the sale price is still theft.

What did you lose in this theft?

Is there really nothing in your home right now you would be sad if someone took and just gave you the money you paid for it?

Even a digital copy of a movie may not be so easy to replace on the services I have access to.

Stores are not allowed to go home to people and take back the stuff they sold, even if they refund the price. Neither should a company that advertise “pay this price and own this movie” rather than “pay this price and rent it for an indeterminate time”.

This is a gross misunderstanding and misrepresentation of CMake.

You lead with this, but all I see in your reply is an explanation of why it works exactly the way I described. That explanation apparently it is: “because not everyone in the ecosystem acts the way CMake developers would want them to”, which I read as “CMakes design for external dependencies is broken.” The fact is, where we are right now, today, the find_package/config script design in CMake frequently makes resolving external dependencies far more painful than it already is without that complication.

That sounds like a lot of repetitive work, doesn’t it? So why not provide CMake-provided scripts with the distribution?

I believe my previous reply gives a very clearly answer: because we get stuck in a situation with multiple competing providers of ‘scripts’ that compete against each other and may apparently all change in backwards breaking ways between releases of CMake, releases of the library in question, and releases of package managers like vcpkg who have taken on themselves to fill in missing scripts.

In the end, it is me who have to dig deep into someone else’s mess of CMakeLists.txt:s to try to unravel the mystery of what feature identifiers they expect from that external depedency and how they expect them to work in the find_package/config script the developers happened to use at the time, so I can then go on an archaeological expedition through all possible providers of that config - including older versions of CMake itself to track it down. Multiply with the number of dependencies - which sometimes is up in the hundreds - and it should be clear why this is a horrible, horrible design of a build system.

If we had to stay with CMake’s broken design for this, at the very least it would need some form of declaration of dependency config scripts with a provider name and a semantic version. That way the problem would at least be solvable.

However, it is more or less only CMake that has this issue in its attempt to be so ‘meta’ about everything. Libraries already come with a build-system independent way to specify features: they are split over several library files and software using that dependency choose which ones to link with - using file names. This works well in nearly every other build system. I don’t get the motivation to try to abstract this into an interface that (for the reasons we’ve discussed above) introduces another intermediate dependency layer.

If the worst point you can make about CMake is the cmake config scripts it bundles, then I’m afraid you are very opinionated over irrelevant details that are immaterial to the discussion.

IMO the main task of a build system is to manage inter- and intradependencies to build the software correctly. So, to me, this failure is truly a fundamental strike against it. If I cannot build your software because I cannot sort out your undeclared, unversioned implicit ‘config’ dependencies, I don’t have much use for other features your build system may or may not provide.

I really could not disagree more. CMake is a terribly designed build system.

One of the most crucial things for a build system is to find and link dependency libraries. How does CMake do this?

Each CMake release distributes its own set of library-specific (!) find_package modules. These change between releases, sometimes in backwards breaking ways. Providers of some of these libraries don’t always like how the central CMake find_package module work, the options they provide, etc. and thus provide their own, incompatible, find_package modules. On top of this, some software package systems, e.g. vcpkg ALSO provides competing find_package modules, also incompatible and sometimes with exactly the same name. And, of course, sometimes no such module is available, and the developers of the software using the library provide their own, or just side-step the find_package system .

The end result is a total mess that can sometimes be nearly impossible to untangle without knowing exactly what environment the developers themselves use. Furthermore, you want to build older releases? Forget that, unless you are prepared to hunt down the exact versions of cmake, vcpkg, and libraries that the developers used at that point in time to get hold of the magical combination of find_package modules that actually builds the package. This is work of far higher complexity than matching semantic version strings, which is what we typically do with other build systems.

My impression is that the only people who like CMake are people who use it to build their own software and thus never run into this issue since it obviously works in their own environment that they’ve adapted the CMake build rules to. But, put someone else’s complex multi-dependency CMake project in their hands and ask them to build a 4 year old version and (1) watch them give up and (2) observe them then claim those “other” CMake developers just don’t know what they are doing. (When, in reality, the exact same problem applies also to their own software).

I have many more gripes with CMake than this, but I guess this rant is already long.

make.include was the perfect build system. Everything went downhill from there.

While a broad concept, in the context of your question, science is a metod to derive knowledge from observations.

Alternatives to the scientific method is to guess or to obtain knowledge from others. (Most other ways I can come up with, e.g. “religion” can still be sorted under these two.)

Obtaining knowledge from others is great, but may not always be available, and the quality of the knowledge derived this way depends on the reliability of the source.

For the other alternative, every sensible metric shows how science is a better method than guessing to derive knowledge.

As a different, more techy, solution that can work depending on the people you collaborate with, is to use a hosted Git service for collaboration (if you want to stay completely open source, a self-hosted GitLab).

Then, change your publication workflow to write in Markdown, ReST, or one of the other ascii formats that previews correctly, and set up your CI to render the documents automatically into, e.g., pdf:s using a converter. There are all kinds of converters from Markdown/ReST -> docs, presentation, etc. formats that are as competent - if not more so - than the usual office suites. This setup offers both online editing in the GitLab instance and offline by local cloning of the Git repo.

The side effect is that this system very seriously records and preserve your document history. You can see exactly who, at what point, changed, added, and removed things. For some types of documents, this can be very important.