this post was submitted on 01 Oct 2023
17 points (100.0% liked)

C++

1783 readers
1 users here now

The center for all discussion and news regarding C++.

Rules

founded 1 year ago
MODERATORS
17
CMake Guidelines (developer.mantidproject.org)
submitted 1 year ago by lysdexic to c/cpp
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago

I 've tried to explain what the problem is with CMake's design from the view of someone who has to build a lot of other people's software. Your response just seem to be ad hominem attacks, a reiteration of the underlying problem, and CMake's broken "solution" to it; I don't see much respons to my actual points.

I understand that you feel strongly that the issue of how to locate all those many undeclared, unversioned config files - that for all intents and purposes are hidden build dependencies - is outside CMake's responsibilities. You are allowed that position, but it doesn't change that locating these dependencies is one of the reasons it is significantly more work to build software that uses CMake than other build systems.

A central point of disagreement, I think, is that CMake is designed around the idea that there is a massive value in the meta-abstraction of the build description into something completely platform and environment-independent. It is possible to question how useful this is in general - however - even from the position that this is a great idea, IMO, in practice, CMake largely fails to deliver this meta-abstraction. The builds still tend to only work on systems and in environments on which they have been tested. And, in that case, what is really the benefit of this meta-abstraction over, e.g., "if win64 then ..." "if ubuntu then ..."?