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. QMake -- OBJ_DIR behaves differently on Linux than on Windows
Forum Updated to NodeBB v4.3 + New Features

QMake -- OBJ_DIR behaves differently on Linux than on Windows

Scheduled Pinned Locked Moved Solved General and Desktop
3 Posts 2 Posters 438 Views 2 Watching
  • 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.
  • R Offline
    R Offline
    Robert Hairgrove
    wrote on last edited by Robert Hairgrove
    #1

    Using Qt 5.12.9 on Windows and Ubuntu Linux 18.04...

    I want to have all of my temporary files written to different places depending on whether I am doing a debug or release build.

    On Linux, this works as expected (in my .pro file):

      OBJECTS_DIR = ./.obj
      MOC_DIR     = ./.moc
      RCC_DIR     = ./.qrc
      UI_DIR      = ./.ui
    

    My default build directory is set to the following string in "Tools/Build & Run/Default Build Properties":

    build/%{JS: Util.asciify(%{BuildConfig:Name})}
    

    So when I do debug and release builds on Linux, I see the following directory structure:

    MyProject
    ⌙  MyProject.pro
    ⌙  <other directories...>
    ⌙  build
        ⌙ Debug
            ⌙.obj
            ⌙.moc
            ⌙.qrc
            ⌙.ui
        ⌙ Release
            ⌙.obj
            ⌙.moc
            ⌙.qrc
            ⌙.ui
    

    But on Windows, qmake always puts these directories one level ABOVE where I actually want to have them, i.e.:

    MyProject
    ⌙  MyProject.pro
    ⌙  <other directories...>
    ⌙  build
        ⌙.obj
        ⌙.moc
        ⌙.qrc
        ⌙.ui
    ⌙  Debug
    ⌙  Release
    

    This leads to numerous problems with DLLs on Windows since in order to build at all, I have to do a clean build before changing the configuration from Debug to Release.

    Therefore, in my .pro file, I have the following:

    unix {
      OBJECTS_DIR = ./.obj
      MOC_DIR     = ./.moc
      RCC_DIR     = ./.qrc
      UI_DIR      = ./.ui
    }
    win32 {
      CONFIG(debug) {
        OBJECTS_DIR = ./Debug/.obj
        MOC_DIR     = ./Debug/.moc
        RCC_DIR     = ./Debug/.qrc
        UI_DIR      = ./Debug/.ui
      }
      CONFIG(release) {
        OBJECTS_DIR = ./Release/.obj
        MOC_DIR     = ./Release/.moc
        RCC_DIR     = ./Release/.qrc
        UI_DIR      = ./Release/.ui
      }
    }
    

    Now, when I build on Windows, the temporary directories are placed under the Release subfolder, even when building in Debug mode!

    I must be missing something?

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

      Hi,

      If memory serves well, this is an idiosyncrasie from Visual Studio that qmake can essentially do nothing about.

      That said, it has become pretty unusual to do it that way since out of source builds have become standard. If you really want to move these build artifacts to specific folders, your should use OUT_PWD. This way you should start at the top of the build folder.

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

      R 1 Reply Last reply
      0
      • SGaistS SGaist

        Hi,

        If memory serves well, this is an idiosyncrasie from Visual Studio that qmake can essentially do nothing about.

        That said, it has become pretty unusual to do it that way since out of source builds have become standard. If you really want to move these build artifacts to specific folders, your should use OUT_PWD. This way you should start at the top of the build folder.

        R Offline
        R Offline
        Robert Hairgrove
        wrote on last edited by Robert Hairgrove
        #3

        @SGaist Thank you for pointing out the OUT_PWD variable.

        [EDIT: this is using MSVC 2015 on Windows 10, BTW]

        Turns out that one of the problems I was having was from using CONFIG(debug) and CONFIG(release) instead of:

        CONFIG(debug, debug|release) {
        ...
        }
        CONFIG(release, debug|release) {
        ...
        }
        

        Even so, In the meantime, I have tried lots of things, but qmake and/or MSVC seem to ignore everything except for the original way I did it for Linux, i.e.:

         OBJECTS_DIR = ./.obj
         MOC_DIR     = ./.moc
         RCC_DIR     = ./.qrc
         UI_DIR      = ./.ui
        

        If I have defined my default build directory as ./build in the Tools/Options settings and .build/Debug and build/Release in the project's build settings, then I get the following structure (which I can live with since it separates the temporary artifacts created in the two configurations debug and release):

        <project directory>
          ↪build
           .qstash file
           Makefile
           Makefile.Debug
           Makefile.Release
           .rc file
            ↪Debug
              ⌙.obj
              ⌙.moc
              ⌙.qrc
              ⌙.ui
              ⌙debug   <== has .EXE file
              ⌙release <== always empty
            ↪Release
              ⌙.obj
              ⌙.moc
              ⌙.qrc
              ⌙.ui
              ⌙debug   <== always empty
              ⌙release <== has .EXE file
        

        Certainly not as elegant as on Linux, but it's not a big deal. At least this way I can do a quick clean and delete the stash file as well (which it never does when running "Clean" from within Qt Creator).

        Marking this now as SOLVED.

        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