And while we are on the subject of finding libs. Is it possible to somehow indicate that a library you are trying to link isn't compatible with the compiler? Somethe _other_ than "unresolved external" error that can indicate anything from lib not being where you want it to be, a mistype in the path, incorrect lib version or, indeed, binary incompatibility. .
On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko <enmarantis...@gmail.com> wrote: > Wouldn't it be more reasonable to implement something like OptionalDepends > where you could just list all possible dependencies in the order in which > it should be loaded? > > On Tue, May 14, 2019 at 9:26 PM Иван Комиссаров <abba...@gmail.com> wrote: > >> I would like to discuss the way how external dependencies should be >> searched by qbs. >> >> While implementing support for the protobuf I found that there several >> place where a generic c++ can come from. >> >> 1. It can be detected via pkg-config >> 2. It can be detected using probes >> 3. Other pkg-config-like tools? Maybe Vcpkg? >> 4. It can be the part of the project. >> >> I am not sure if we need to support 4, but if the mechanism of library >> searching will be based on the Depends item, I don’t see why user can’t add >> a «zlib» product that will be fetched prior to system modules. But anyway, >> that’s not the point. >> >> The point is that for now, I have to write stuff like >> >> Depends { >> >> name: "internal.libprotobuf.pkgconfig" >> >> condition: _autoDetect >> >> required: false >> >> } >> >> Depends { >> >> name: "internal.libprotobuf.probes" >> >> condition: _autoDetect && !internal.libprotobuf.pkgconfig.found >> >> required: false >> >> } >> >> >> Note, that libprotobuf.pkgconfig and libprotobuf.probes are *different* >> modules >> in different folders under qbs/modules. >> In case I want to add third way to fetch a library, I will require third >> module and third Depends item. Too much boilerplate for a modern build >> system. >> >> This comes from the limitation that modules are loaded only based on >> their condition and priority and it is not possible to use Probes in >> conditions. I guess, this limitation comes from the fact that probes are >> heavy to evaluate, but I’m not sure. >> Either that limitation should be removed, or we can extend the way Qbs >> loads modules by adding property bool recover to the Module which tells >> Qbs to try loading next module in a chain (with lower priority) if loading >> «best suitable» module failed. If the property is false by default, current >> behavior will be preserved and we can use it to implement «chain» loading >> by simply writing Depends { name: "internal.libprotobuf" }. >> >> Next thing I want to discuss is the way how Qbs should search for >> libraries using Probes. For now, we have IncludeProbe, LibraryProbe and >> FrameworkProbe (for macOS frameworks). It is not very convenient to use >> them directly, but we can wrap them into a ExternalPackage module that >> provides some input properties to tell Probes what to search for: >> >> ExternalPackage { >> >> name: "zlib" >> >> headers: ["zlib.h"] >> >> libraryNames: ["z"] >> >> } >> >> >> We can also provide some properties to tell Qbs where to search for >> libraries or to override some default behavior: >> >> qbs build modules.ExternalPackage.platformSearchPaths:"/opt/usr/lib" >> modules.ExternalPackage.staticLibs:true >> >> That way, we will have mechanism similar to CMake find package module and >> we can provide support for lot of libraries in a *declarative* way. >> >> Any thoughts? >> _______________________________________________ >> Qbs mailing list >> Qbs@qt-project.org >> https://lists.qt-project.org/listinfo/qbs >> >
_______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs