Rejuvenating Autoconf

Posted Oct 28, 2020 22:51 UTC (Wed) by andresfreund (subscriber, #69562)
In reply to: Rejuvenating Autoconf by andresfreund
Parent article: Rejuvenating Autoconf

Oh, another related issue: There - at least not that I have found - isn't a way to to run cmake in an existing build directory that ensures that only the -D parameters in the current invocation take effect (with the rest set their defaults). It's so easy to end up with options lingering around. Having to clean out the build tree is a pretty expensive solution...

Rejuvenating Autoconf

Posted Oct 29, 2020 0:54 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> And, which I think is the really bad part, they don't even work when cmake fails with an error, for crying out loud.

Due to the nature of the options being defined in imperative code, there's no way for CMake to provide everything in the case of an error. On that front, the discussion around a declarative CMake might be of more use to you[1]. However, you will be able to edit what is available at least, so if you have an option that immediately causes an error, it should be in the cache (or at least in the error message assuming the project is nice enough to have good error messages) for editing.

> isn't a way to to run cmake in an existing build directory that ensures that only the -D parameters in the current invocation take effect

Without CMake knowing what the actual defaults are, this would be hard. It would be possible with the issue I linked to above once CMake does have the concept of `Option<UserSetting>`. I've added this idea to that issue[2], thanks.

[1]https://gitlab.kitware.com/cmake/cmake/-/issues/19891
[2]https://gitlab.kitware.com/cmake/cmake/-/issues/14756#not...