On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote: > On 30/10/2018 13.17, Oswald Buddenhagen wrote: > > it's much easier to make qbs generate **and even read** cmake > > interface files than to re-architect cmake to make it, well, sane. > (Emphasis added.) > > No, really, it isn't. > it is, despite the below.
> A CMake interface file is Turing-complete and can do anything that > CMake can do. > yes, and when i looked a few days ago into the code cmake auto-generates, my jaw dropped. this is total insanity. > In order to actually implement the ability to read CMake interface > files (without corner cases), you basically have to *be* CMake. > in the most extreme case one could actually make a qbs plugin that links against the relevant cmake code. > If you assume that you will only have to deal with some subset, you > will be subject to breakage at any time. > yes, but that's not such a big deal, because most projects just use the auto-exports, and keeping up with changes to that isn't an extraordinarily challenging task. and manually covering the remaining 1% of packages that fail isn't a huge deal, either, esp. once the qbs community grows. and the whole thing would be only a "bridge technology" anyway. ^^ > I would rather see CMake learn to read and output something more > portable, e.g. CPS¹. > from a quick glance, this isn't all that bad, and in fact reflects the strongly declarative concepts i'm envisaging for qbs' interface files. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
