Why are changes in source not always reflected in machine code after build while rebuild works?

Question

Sometimes when I change code in my Qt project (Qt Creator 2.1.0 with mingw32), the changes don't get reflected in the produced machine code after building it. This happens mostly when I change things like default values in constructors or the order of parameters in methods/constructors. Usually, a full rebuild fixes that (but takes a few minutes).

I'm helping myself by deleting the generated executables or librarys before building, which seems to help most of the time. Does that mean that theres something going wrong when linking the object files?

I'm coming from java/.net and I'm used to a different behaviour. I'd be happy if anyone could explain me what I'm doing wrong and/or point me to some related articles.

Thank you!

Do the object files remain unchanged too? – Björn Pollex Mar 29 '11 at 09:32 — Björn Pollex, Mar 29 '11 at 09:32

Frank Osterfeld · Accepted Answer · 2015-04-10T18:25:06.207

15

Usually, after a change in a header, all source files including that header should be rebuilt. However, qmake is a bit peculiar in this regard, you need to set DEPENDPATH for include folders other than the current directory. E.g., if you have

INCLUDEPATH += somepath_in_my_project

also add

DEPENDPATH += some_path_in_my_project

Only with DEPENDPATH, files built by the .pro files are rebuilt if some header in some_path_in_my_project changes (if they include that header)!

I suggest to add for each INCLUDEPATH line an identical DEPENDPATH line, unless you include some system directory you don't expect to change.

Edit:

A similar problem exists when linking statically with qmake: If the static lib foo.a changes, binaries linking against it are not relinked. That's a bug in QMake, not generating the correct dependencies.

A workaround I found in a former project:

static:unix:TARGETDEPS += path_to_my/somestaticlib.a
static:win32:TARGETDEPS += path_to_my/somestaticlib.lib

Edit edit:

Since some time (Qt 5?), above code should use POST_TARGETDEPS instead of TARGETDEPS.

edited Apr 10 '15 at 18:25

answered Mar 29 '11 at 10:04

Frank Osterfeld

24,815
5
58
70

It means recompiling all source files if any of include files in DEPENDPATH is changed? It seems pretty close to full recompile. – Serge Dundich Mar 29 '11 at 10:16
Serge Dundich: No, the .cpp file is only recompiled if it includes a header that changed. It works on per-file level. – Frank Osterfeld Mar 29 '11 at 10:23
2

DEPENDPATH was the keyword I was looking for, thank you so much! – atamanroman Mar 29 '11 at 11:16
1

Do you build statically? I've had issue like this with static builds. – Frank Osterfeld Mar 29 '11 at 14:32
Yes we are doing static builds. I'll investigate that further and keep this question up to date if I find any new information. You don't know any stuff related to that kind of issues with static builds and Qt? – atamanroman Mar 30 '11 at 11:24
atamanroman: I added the workaround from a former project. IIRC that fixed it. – Frank Osterfeld Mar 30 '11 at 12:26

score 3 · Answer 2 · answered Mar 29 '11 at 09:36

The most common case for that are broken dependencies. In the particular case of default arguments to functions, they are resolved at the place of call, so if you just recompile the function, the code will be exactly the same. You need to recompile the caller. If the dependencies in the project are not correct and the build system does not detect that it needs to recompile the caller, and only recompiles the callee then you will see that effect.

Analyze the dependencies and fix them.

Example:

// what you write                  // what the compiler generates
void foo( int i = 0 ) {}           void foo( int i ) {} // default removed
int main() {                       int main() {
   foo();                             foo( 0 );         // compiler injected
}                                  }

How to you suggest to specify a known dependency in QMAKE .pro project file? — Serge Dundich, Mar 29 '11 at 10:18

Serge Dundich · Answer 3 · 2011-03-29T10:11:36.713

3

If you're listing all relevant header files in a project file this shouldn't happen. But actually it happens all the time because QMAKE is buggy (it has known problems with dependencies generation unfixed for years). So better clean it and recompile or use Cmake. And also QMAKE knows nothing (and detect almost nothing) about dependencies between source files and header files and that may lead to problems like that.

edited Mar 29 '11 at 10:11

answered Mar 29 '11 at 09:39

Serge Dundich

4,221
2
21
16

Renaming and removing files is the easiest way to screw up qmake. Very bad that nobody in the QT team gets priority for fixing this bugs. – Lothar Feb 12 '15 at 00:12

score -1 · Answer 4 · answered Mar 29 '11 at 09:40

If your Makefile (or your moral equivalent to a Makefile) is missing dependency information, then you can get out-of-sync builds. For every file with #include "header.h", you need to make sure the Makefile puts header.h as a dependency on that file.

Here is a small piece of a Makefile I've got:

parser_yacc.c parser_yacc.h: parser_yacc.y parser.h
        $(YACC) $(YFLAGS) -o parser_yacc.c parser_yacc.y

parser_lex.c: parser_lex.l parser_yacc.h parser.h
        $(LEX) ${LEXFLAGS} -o$@ $<

parser_lex.o: parser_lex.c parser.h parser_yacc.h
        $(CC) $(EXTRA_CFLAGS) -c -o $@ $<

parser_misc.o: parser_misc.c parser.h parser_yacc.h af_names.h cap_names.h
        $(CC) $(EXTRA_CFLAGS) -c -o $@ $<

Each object file clearly depends upon the corresponding source and header files. If we forgot cap_names.h, then parser_misc.o wouldn't be rebuilt when cap_names.h is modified. Bugs can ensue.

I'm afraid the fix is long and tedious: inspect every file, make a list of its dependencies, and add missing dependencies to the Makefile. On a Linux platform, you could use the strace(1) tool to discover which files the compiler needs to open when compiling each source file, and improve the dependencies with that list. I do not know if any similar tool exists on Windows, but it would be worth spending a few minutes looking for one before diving in.

Makefile is autogenerated by QMAKE utility. – Serge Dundich Mar 29 '11 at 10:10 — Serge Dundich, Mar 29 '11 at 10:10

Why are changes in source not always reflected in machine code after build while rebuild works?

4 Answers4

Linked