On Dec 18, 2018 12:33 PM, "Matthew Woehlke" <mwoehlke.fl...@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
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development