How to create multiple build configurations in .pro

bsdillon

I am trying to create four different buid configurations and use my .pro to set up configuration differences between them. I put the full details in a stackoverflow question (https://stackoverflow.com/questions/63082818/how-to-create-multiple-build-configurations-in-qt).

The problem is that I am not getting different builds. I have a debug and a release, but I cannot get it to create the non-GUI version of debug and release. This is what I expected to work.

build_pass:CONFIG(Debug) {
message("this is a debug build")
TARGET = "Project_D"
message($${TARGET})
DESTDIR = $$HOME/debug
}

build_pass:CONFIG(DebugHeadless) {
message("this is a debug build")
TARGET = "Project_HEADLESS_D"
message($${TARGET})
DESTDIR = $$HOME/debug
}

build_pass:CONFIG(Release) {
message("this is a release build")
TARGET = "Project"
message($${TARGET})
DESTDIR = $$HOME/release
}

build_pass:CONFIG(ReleaseHeadless) {
message("this is a release build")
TARGET = "Project_HEADLESS"
message($${TARGET})
DESTDIR = $$HOME/release
}

But the messages indicate it is not working.

Project MESSAGE: this is a release build
Project MESSAGE: Project
Project MESSAGE: this is a debug build
Project MESSAGE: Project_D

What is the right .pro syntax to create four distinct builds in different configurations?
What is the right command line syntax to force of of the four builds (I think I'm already getting all)?

bsdillon

@J-Hilk Okay. That at least got me in the right area. My inherited code used buildpass, but you were right that the CONFIG function was the key. You really should get the credit on stackoverflow.

My final solution has CONFIG both to determine if it is build/release and to determine if it is GUI/NoGUI.

CONFIG(GUI)}
  ... add GUI-related details
  CONFIG(release, debug|release){
    message("Project")
    ... add release details
  }
  CONFIG(debug, debug|release){
    message("ProjectD")
    ... add debug details
  }
}

CONFIG(NoGUI)}
  ... exclude GUI-related details
  CONFIG(release, debug|release){
    message("Project_HEADLESS")
    ... add release details
  }
  CONFIG(debug, debug|release){
    message("Project_HEADLESS_D")
    ... add debug details
  }
}

SGaist

Hi and welcome to devnet,

Where is DebugHeadless coming from ?

J.Hilk

@bsdillon you're in luck, I've been fighting with qmake and *pro files for the last couple of days, and should be able do help here :D

First of, you're supposed to check for debug or release build in this way:

CONFIG(release, debug|release)  {
#Release build
}

CONFIG(debug, debug|release) {
#Debug build
}

and you can use the requires check, to check for your own CONFIG += DebugHeadless

requires(DebugHeadless) {
 #Debug headless build
}

That's how I'm using it, and how its finally working for me :D

bsdillon

@SGaist I defined two additional build configurations in the Project tab. DebugHeadless and Headless are the names of those configurations.

@J-Hilk Okay, that makes a little more sense. I saw that in other documentation, but I believed you could select which build you wanted at that point. Alright. I'm away from my computer (at 12:48am local time), but I will try that as soon as I get back. If you have a stackoverflow account, you might as well get the credit for a good answer there.

bsdillon

@J-Hilk Okay. That at least got me in the right area. My inherited code used buildpass, but you were right that the CONFIG function was the key. You really should get the credit on stackoverflow.

My final solution has CONFIG both to determine if it is build/release and to determine if it is GUI/NoGUI.

CONFIG(GUI)}
  ... add GUI-related details
  CONFIG(release, debug|release){
    message("Project")
    ... add release details
  }
  CONFIG(debug, debug|release){
    message("ProjectD")
    ... add debug details
  }
}

CONFIG(NoGUI)}
  ... exclude GUI-related details
  CONFIG(release, debug|release){
    message("Project_HEADLESS")
    ... add release details
  }
  CONFIG(debug, debug|release){
    message("Project_HEADLESS_D")
    ... add debug details
  }
}

J.Hilk

@bsdillon Gerate, that you managed to make it work! (Correctly) Setting up a pro file is no easy task and often very frustrating.

Sometimes I wonder, if I shouldn't just make the change to cmake, eventually it's going to happen.

You really should get the credit on stackoverflow.

I do have a stackoverflow, account, I made it years ago to thank someone for a solution and to make an upvote. No idea if it's still valid :D