Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Lib dependencies and QMake variables not changing when modified in a .pri function

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

Scheduled Pinned Locked Moved Unsolved General and Desktop
7 Posts 4 Posters 825 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    cauri
    wrote on last edited by cauri
    #1

    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?

    C 1 Reply Last reply
    0
    • C cauri

      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?

      C Offline
      C Offline
      cauri
      wrote on last edited by
      #2

      Probably I posted in the wrong section

      1 Reply Last reply
      0
      • SGaistS Offline
        SGaistS Offline
        SGaist
        Lifetime Qt Champion
        wrote on last edited by
        #3

        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.

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        1
        • C Offline
          C Offline
          cauri
          wrote on last edited by
          #4

          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.

          1 Reply Last reply
          0
          • VRoninV Offline
            VRoninV Offline
            VRonin
            wrote on last edited by
            #5

            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

            "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
            ~Napoleon Bonaparte

            On a crusade to banish setIndexWidget() from the holy land of Qt

            B 1 Reply Last reply
            0
            • VRoninV VRonin

              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

              B Offline
              B Offline
              Bonnie
              wrote on last edited by Bonnie
              #6

              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.

              1 Reply Last reply
              0
              • C Offline
                C Offline
                cauri
                wrote on last edited by cauri
                #7

                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

                1 Reply Last reply
                0

                • Login

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups
                • Search
                • Get Qt Extensions
                • Unsolved