My own header file not found in release mode but works fine in debug mode

JohnGa

Hello,
As a matter of convention, all the header files in my project include other header files via the "#include" directive. My project does not use forward declarations in the header files.

All these days QtCreator built debug/release profiles without issues. Suddenly, the release mode does not build. I get a

"fatal error: xxxxxxxxx.h: No such file or directory" error.

The header file that it cannot find is in the same directory as the file including it.

This is similar to the issue that was presented in: https://forum.qt.io/topic/61080/includepath-cannot-open-include-file. Please see the very last message in this link.

As a workaround, in the .pro file, I am using this undocumented qmake setting: With this setting in the pro file, my release executable builds correctly.

# undocumented qmake flag to force absolute paths in make files
QMAKE_PROJECT_DEPTH = 0

Does anybody know why the debug executable might build correctly, but not the release executable? Is it okay to use this undocumented qmake setting?

Thanks

jsulm

@JohnGa Can you show your pro file?

Tyrannic

I am also having this issue with a project, although it fails on release and debug mode.

Our project uses several subdir templates throughout our build tree for the source code along with a few internal libraries. We tracked the problem down to Windows having a limitation on relative paths. When qmake (or cmake) generates the make files by default, all of the paths are relative. If that path gets too long, I believe the limit is ~260 characters. Then when qmake or make are running, they'll fail to resolve the relative path and go into undefined behavior.

We've been unable to solve the issue for months without just moving our build tree to the root of our drives to shorten the paths, but now with some extra classes with rather long names, that solution no longer works. I've tried to put the QMAKE_PROJECT_DEPTH = 0 setting in our root .pro file that acts as our subdirs template .pro file with no luck. Setting that variable (at least in that .pro file) has no change on the paths that Qmake generates.

Our build tree is roughly (the names were changed, but it's the exact same layout) as follows:

├───projectcode
│   ├───projectcode.pro
│   └───header & source files
├───corelib
│   ├───code
│   │   ├───code.pro
│   │   └───header & source files
│   └───tests
│       ├───tests.pro
│       ├───UnitTest1Project
│       └───UnitTest2Project
└───projecttests
    ├───projecttests.pro
    ├───UnitTest1Project
    └───UnitTest2Project

I've looked at this issue: https://forum.qt.io/topic/38990/solved-qmake-infinite-loop
Our issue is not time related

I've also looked at this issue: https://forum.qt.io/topic/51402/solved-qmake-stuck-in-infinite-loop/3
Building directly from the command line via MSYS doesn't work

Needless to say, we've not been able to find a solution to this other than not building on Windows. Taking our project to Linux works fine with absolutely no issue, but we have certain dependencies that will not let us fully switch to strictly Linux development.

Thanks to anyone who could shine any light on this.

JohnGa

Tyrannic,
Thanks for the detail. I consistently had the issue where the failure would happen only with the release build on Windows. My projects use the exact same source tree, for debug/release builds. For me, using the absolute path setting, consistently resolves the issue in multiple projects. With that setting in place, qmake definitely generates makefiles with absolute paths.

Not sure if it helps you any, but wanted to add my datapoints.

Also, did you try removing the 260 char limit on windows. If you google, there are plenty of guides on how to change the Windows 10 settings.

Thanks.

Tyrannic

John,

I did look into removing the path limit from Windows, but the only solutions I found for that were to remove the path limit for absolute paths, not relative paths. If you have a solution to make the relative path limit go away, please share. Your issue may be slightly different than mine.

My issue is definitely relative path length related. Simply shortening the path solves the problems, but we can't go about making all of our class names 4 characters long. I mean, I guess we could, but you probably get what I mean.

JohnGa

@Tyrannic
I would definitely keep experimenting until you get the QMAKE_PROJECT_DEPTH = 0 setting to take effect. Without this setting in my pro file, I have absolutely confirmed my makefiles use relative pathing everywhere in the makefile. With the setting, I see absolute paths everywhere.

We know relative paths is the root cause of your problem. I have confirmed that this setting definitely generates makefiles with absolute paths. To me it feels like, making this setting take effect will solve your issue.

Can you take a separate small Qt project, and try this setting? For reference, I put this setting at the very top of my pro file, just under the TARGET, TEMPLATE, and CONFIG lines. Once you see a makefile with absolute paths everywhere (I mean everywhere in the makefile....every path is either absolute or relative) you can try it in your actual projects. Maybe you need to sprinkle that setting in all your pro files.

I saw this somewhere on the web. Forget QtCreator, from a command line execute "qmake QMAKE_PROJECT_DEPTH=0 your-pro-file-name.pro" on your pro file and see if that generates makesfiles with absolute paths.

Tyrannic

@JohnGa

So I tried putting the QMAKE_PROJECT_DEPTH=0 into the arguments of QMake within QtCreator and it did generate absolute paths this time. However, simply putting that variable into my .pro file still does not generate absolute paths. Perhaps you cannot include that variable within a .pro file that is setup as a subdirs project (TEMPLATE = subdirs)?

JohnGa

@Tyrannic Did you try putting that setting in every .pro file?

Also, why isn't setting the arguments of QMake in QtCreator an acceptable solution for your team given the freedom it buys you? Wouldn't having every team member set the setting once would be a better world to live in, than having to shorten names,etc.?