[Development] Build system for Qt 6

Ray Donnelly mingw.android at gmail.com
Tue Dec 18 20:00:01 CET 2018


On Dec 18, 2018 12:33 PM, "Matthew Woehlke" <mwoehlke.floss at gmail.com>
wrote:

On 15/12/2018 15.49, Ray Donnelly wrote:
> Do you know for example that cmake will find dlls in C:\Windows\System32,

Uh... yeah? I think most people *expect* that...

Would you also rather CMake didn't look in /usr/lib[64] on Linux
systems? *Why*?


Because you are then building software that (possibly unbeknownst to you
unless you are an expert in the arcane ways of cakeh, cannot work without
the presence of any such found DSO (or ABI and SONAME compatible DSO in the
RPATH). Compilers will happily tell you what implicit folders they will
look in on Linux and cmake does query that (it does not pay the same
respect to static linkers even though I sent in a patch for exactly that)
but this isn't of any help on Windows. Explicit is always better than
implicit for this kind of thing and hermeticity is important as is
reproducability. Take a simple example of a build that found your own
zlib.dll yesterday but no longer does today,  because you installed some
random 3rd party software that happened to put zlib.dll in System32 in the
meantime. This particular feature bites all the time. As I said 'ok' for
developers but not for packagers.


> find_package is still inscrutable, and it's for sure the cause of
> most issues we see as software packagers).

Well, yeah, find modules are... not ideal. Modern software should be
providing package configuration files with exported targets.

If we switched to CPS¹ (SHTDI!), that would be even better
(mostly-human-readable files that don't use CMake syntax).

(¹ https://mwoehlke.github.io/cps/)

-- 
Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181218/0e02514d/attachment.html>


More information about the Development mailing list