Unsolved #include repost
-
@Pl45m4 Agree with your approach, however, the initial question was about why "#include" does not work as expected AND
why the project tree and project file entries make no difference OR more precisely does not effect the complication. My usage of btscanner is purely selfish – it works in Qt - as opposed to many other “sample codes” , and that is OK with me.What is NOT OK is tool likes Qt Creator messing with C language syntax by adding layers of
poorly explained “STUFF” , such as inventing syntax “/../../xxx” where #include <FILIE>; should do.As far as “samples” being second grade code – something about advertising Qt comes to mind, and I shall leave that as is.
-
@J-Hilk
I will repeat what I have said already and add - the syntax for #inlcude has not changed since it was introduced. The Qt Creator adds stuff which is not only odd but is not used during compile.
Yes, I did not cut and paste "the real Mc Coy" definition as you did.
Was MY definition incorrect ?
I am not sure if adding PATH (to pro file) is necessary - it is already in project tree and if it is important it should be added to pro file by Qt Creator.Appreciate all the comments and suggestions, it is very helpful to get my project going.
Thanks
-
@AnneRanch said in #include repost:
What is NOT OK is tool likes Qt Creator messing with C language syntax by adding layers of
poorly explained “STUFF” , such as inventing syntax “/../../xxx” where #include <FILIE>; should do.Qt Creator is an IDE, including a C/C++ editor and a debugger. It does not, and cannot, alter the syntax of any language. If it did, programs would not compile. The compiler/linker is not a Qt component.
Whatever
#include
s you have shown in your code will conform to https://en.cppreference.com/w/cpp/preprocessor/include, or similar, as per @J-Hilk 's post. Assuming your are usinggcc
, its documentation should provide any details on handling/how to pass directories on the compile line, etc.#include <>
tends to look in some system directories which#include ""
does not. Handling of a relative path with..
is probably compiler-implementation-specific. -
@JonB This comments i misinterpreters this entire thread.
Nobody is challenging Qt as IDE "interface " to make and compiler / linker.
What I questioned is what appears superficial "includes" with no visible effect on processes. If common item likes #include has to be done manually we have very poorly functioning "IDE", nothing to do with complier.Since you mentioned complier - where can I read Qt Creator compile options ?
I have 4 processor system and like to add "-j" option to speed things up.But I'll post this separately - different subject
-
@AnneRanch said in #include repost:
@JonB This comments i misinterpreters this entire thread.
No, it doesn't. You think that Qt Creator is doing something funny about
#include
s, and keep saying so. It is not. -
@AnneRanch said in #include repost:
I have 4 processor system and like to add "-j" option to speed things up.
https://stackoverflow.com/questions/8860712/setting-default-make-options-for-qt-creator
(4 processor cores, I assume)
-
This post is deleted! -
@Pl45m4 Pardon my ignorance , but -j is a complier option .
When I added it to "make" it did not show in compiler output.
Which brings another question - who is on first - "make" or "qmake" or both ?
And since I am not allowed to do multiple posts - why is there "build" and "rebuild" ? Back in the beginning of programming - when file was "dirty" it would get rebuild AUTOMATICALLY when "build" was requested anyway.
. -
"Build" only builds (link +compile) files that have changed ("dirty" files).
"Rebuild" will build all files, regardless whether they have changed or not. And this could take several minutes or even more in huge projects.The path in your error msg says "Qt_Repository Copy". Is that the right one? Did you move or rename any files? Try to rename any button (by double clicking on e.g. "Scan") in your current ui file (just the button text, not the actual widget name) and run your program. If the name is still the old one, your program is probably using a different ui file.
-
@AnneRanch said in #include repost:
who is on first - "make" or "qmake" or both ?
qmake
...- ...parses your *.pro file and generates your Makefile
- ...parses your *.ui file and generates *.cpp and .h files
- (and more)
make
parses your Makefile and runs your build tools