Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Lib dependencies and QMake variables not changing when modified in a .pri function



  • Hi all,

    in my repo I have tens of different libraries. When I add a new dependency in one of them I have to modify all the applications and libraries that depended on them, all the .pro files. It's so time consuming, I don't know if there is a better way, but now I'm trying to create a .pri for each library in order to make this process easier in some way. During this process I've found the following issue:

    I have created a qmake function that includes a .pri file:

    defineTest(add_my_lib) {
        lib_name = $$1
        message("adding lib$$lib_name ")
        include(mypath/$${lib_name}.pri)
    }
    

    in this .pri file I have added lines to include a library:

    INCLUDEPATH += /pathToLib/src
    LIBS += -L/pathToLib/lib -lmylibname
    

    The problem is that for some reason in the .pro that calls add_my_lib the INCLUDEPATH gets reset. It looks like INCLUDEPATH is a variable that cannot be modified by functions. Or better, it can inside the function but the values do not get propagated in the caller .pro file.

    Is this the correct behavior or am I doing something wrong?



  • Probably I posted in the wrong section


  • Lifetime Qt Champion

    Hi and welcome to devnet,

    No you did not but you might be using a technique that nobody used before.

    You should add which version of Qt you are using as well as platform you are running on.

    A complete minimal project showing the issue would also be appreciated so everybody can test that.

    One thing though, if adding a new dependency in one of your sub-projects bubbles up that much, it might also mean that you might not be doing the right thing. Does your other libraries and applications use that dependency in one form or another ? If not, then you should be implementing your underlying library such as it does not expose unnecessary details and thus the need for all the others to link directly to these libraries.



  • Thank you for your reply. I'm using Qt 5.12.1 and I'm on Linux.

    I have often this problem because my code base uses many small libraries, each one with its purpose. Theoretically this is a great approach, but in order to make it work it needs good tooling support.

    What I thought looks logic to me: if my lib is included by other 1000 libs, tests and apps I don't want to modify all 1000 of them. Perhaps there is some other technique that people use to solve this problem. I know it's possible with cmake, but I haven't found a solution with qmake yet, and modifying everytime the .pro is really bothersome.



  • Can't reproduce the problem.
    I tested with a minimal project:

    .pri

    INCLUDEPATH += mylib/includes
    

    .pro

    QT       += core gui widgets
    
    CONFIG += c++11
    
    INCLUDEPATH += something/includes
    message("Before PRI: $$INCLUDEPATH")
    include(includelib.pri)
    message("After PRI: $$INCLUDEPATH")
    
    
    DEFINES += QT_DEPRECATED_WARNINGS
    
    
    SOURCES += \
        main.cpp \
        mainwindow.cpp
    
    HEADERS += \
        mainwindow.h
    
    FORMS += \
        mainwindow.ui
    
    # Default rules for deployment.
    qnx: target.path = /tmp/$${TARGET}/bin
    else: unix:!android: target.path = /opt/$${TARGET}/bin
    !isEmpty(target.path): INSTALLS += target
    

    If you run qmake you will see in the messages that INCLUDEPATH gets updated just as expected. My guess is that you have an instruction that has INCLUDEPATH = instead of INCLUDEPATH += somewhere after the inclusion of the pri files.

    P.S.
    As you mentioned cmake is much more efficient in handling this kind of things so I would recoment that "build system" for your project



  • I think the problem is trying to set variables in a Test function.
    As I know, the variables in a Test function are not the variables in the .pro file, they are in different scopes.



  • Thank you guys for your feedback.

    Yes, I think the problem is probably in the Test function. I know that also Qt is switching to CMake, but I wonder if there is a temporary solution to fix this problem in some other way


Log in to reply