On 30/10/2018 14.25, Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote: >> In order to actually implement the ability to read CMake interface >> files (without corner cases), you basically have to *be* CMake. >> If you assume that you will only have to deal with some subset, you >> will be subject to breakage at any time. > > yes, but [...] the whole thing would be only a "bridge technology" > anyway.
So why not jump straight to a better way of exchanging package information, and teach CMake to speak that? If you can produce such a system (which is exactly what CPS tries to do), I think CMake would be receptive. Why bother with an interim solution? (BTW, I'm hoping there will be some discussion along these lines at WG21 next week... At least there were two papers in the most recent mailing along these lines.) >> 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. Thanks :-). I've tried to make it plausible and address both likely edge cases and some issues that CMake currently does not handle well, while keeping it reasonably simple. It's mostly lacking implementation, and I haven't had the time/ability to do a lot more than write up the schema. Help would be much appreciated! -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development