On Tue, Oct 30, 2018 at 05:06:44PM -0400, Matthew Woehlke wrote: > 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? > i would be all for it. not sure the message "would you mind accepting that patch? it's just a bit more maintenance work for you, and it would make it easier for everyone else to break your quasi-monopoly and ultimately make your tool obsolete ..." would be *that* easy to sell, though. :D
> >> 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! > for starters just some food for thought: QBS-995 should be implementable on top of it. if you want to go full monty, QBS-942 is your target. one thing i noticed is that you multiplex build variants and other stuff into a single file. this is not helpful for packaging. after much thinking about the matter, i concluded that the interface files should correspond to "atomic linkable entities", which essentially means actual libraries - not one interface to describe all build variants, and not one interface to describe each architecture variant within a multi-arch library. any aggregation of (however) related interfaces should happen on the consumer side (in as far as necessary at all). this is actually closely related to QBS-995. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
