#include repost
-
#include " file " ; searches local directory ONLY and stops
#include <file> ; searches "above " local directoryThe "../../.." syntax seems to go "up the tree" , assuming the referenced project is in "current access". (I need to work on that theory)
Anything else , such as ellipsis or "....." is unknown syntax to me.
Can you provide reference ? -
#include " file " ; searches local directory ONLY and stops
#include <file> ; searches "above " local directoryThe "../../.." syntax seems to go "up the tree" , assuming the referenced project is in "current access". (I need to work on that theory)
Anything else , such as ellipsis or "....." is unknown syntax to me.
Can you provide reference ?@AnneRanch
I think @hskoglund means you've made a typo... -
Here is what works partial path (?) and then full path - the entire project compiles and runs.
Anybody interested to find out WHY it works ?
Perhaps detailed analysis of complier output - now available AFTER the error is gone (!) would be interesting to somebody. ( I could post it)My "solution" is
path (GUI) in "project tree" and (../../..) in x.pro file means NOTHING to the complier. -
Since my original post DID NOT get solved I am taking the liberty t repost with additional info.
I am trying not to reinvent the wheel and putting two WORKING application under one roof.
My task is to add existing files of btscanner apprication into tab dialog.I am using plain "add existing files " and they are being added into correct folders under correct additional sub folders showing the path.
They are added into tab dialog project
I have added this manually
After all this - complier cannot find #inlcude - starting wiht "main.cpp"
Missing device.h in main error
Questions
- What do additional folders with path accomplish ?
- How do x.pro HEADERS gets used or not ge used by whom - makefile or compiler?
- It looks as plain "include device.h" in source file is not sufficient to make / compile - WHERE DO I ADD the necessryn path ?
Addendum
After adding relative path to #include it passed device but not service header. .
Cheers
@AnneRanch said in #include repost:
I have added this manually
Just to add:
This is pure evil :)
Dont use=to change settings... Use+=to add modules to your basic config or use-=to take modules.https://doc.qt.io/qt-5/qmake-project-files.html#declaring-qt-libraries
-
@AnneRanch
I think @hskoglund means you've made a typo...This post is deleted! -
@AnneRanch
I think @hskoglund means you've made a typo... -
Minor , insignificant detail not helping to resolve THIS #include issue.
BTW - I just cut and pasted it from "an official" btscanner example .@AnneRanch
It's a general thing.
As I've said in one of your other posts, examples are minimalistic standalone projects, that are (in most cases) not meant to get improved or extended even further.
So, IMHO it's not a good idea to import a whole example to your own projects and take over the example'sprofile...
I don't want to question your whole idea, but I would say, that there are easier and faster ways to make your own BT Scanner "test" / "example" project.
Or is there anything that forces you, to import the full example? -
@Bonnie Mia culpa - I DID MADE a typo
@AnneRanch to answer your original question, the pro- file offers you the possibility to expand the include path, via
INCLUDPATH += ....in your case
INCLUDEPATH +=$$PWD/../../bluetooth/btscannershould do the trick.
But use it with caution, I find that using INCLUDEPATH convolutes the code more than that it makes it easier to read.
But that maybe just me#include " file " ; searches local directory ONLY and stops
#include <file> ; searches "above " local directorywhere did you get that from?
the actual definition:
- #include <filename>: Searches for the file in implementation-defined manner. The intent of this syntax is to search for the files under control of the implementation. Typical implementations search only standard include directories. The standard C++ library and the standard C library are implicitly included in these standard include directories. The standard include directories usually can be controlled by the user through compiler options.
- #include "filename": Searches for the file in implementation-defined manner. The intent of this syntax is to search for the files that are not controlled by the implementation. Typical implementations first search the directory where the current file resides and, only if the file is not found, search the standard include directories as with (1).
https://en.cppreference.com/w/cpp/preprocessor/include
The only thing that "searches upward" that I now, is qmake in search of a .qmake.conf file
But there may be more 🤷‍♂️ -
@AnneRanch
It's a general thing.
As I've said in one of your other posts, examples are minimalistic standalone projects, that are (in most cases) not meant to get improved or extended even further.
So, IMHO it's not a good idea to import a whole example to your own projects and take over the example'sprofile...
I don't want to question your whole idea, but I would say, that there are easier and faster ways to make your own BT Scanner "test" / "example" project.
Or is there anything that forces you, to import the full example?@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.
-
@AnneRanch to answer your original question, the pro- file offers you the possibility to expand the include path, via
INCLUDPATH += ....in your case
INCLUDEPATH +=$$PWD/../../bluetooth/btscannershould do the trick.
But use it with caution, I find that using INCLUDEPATH convolutes the code more than that it makes it easier to read.
But that maybe just me#include " file " ; searches local directory ONLY and stops
#include <file> ; searches "above " local directorywhere did you get that from?
the actual definition:
- #include <filename>: Searches for the file in implementation-defined manner. The intent of this syntax is to search for the files under control of the implementation. Typical implementations search only standard include directories. The standard C++ library and the standard C library are implicitly included in these standard include directories. The standard include directories usually can be controlled by the user through compiler options.
- #include "filename": Searches for the file in implementation-defined manner. The intent of this syntax is to search for the files that are not controlled by the implementation. Typical implementations first search the directory where the current file resides and, only if the file is not found, search the standard include directories as with (1).
https://en.cppreference.com/w/cpp/preprocessor/include
The only thing that "searches upward" that I now, is qmake in search of a .qmake.conf file
But there may be more 🤷‍♂️@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
-
@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.
@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
#includes 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. -
@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
#includes 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
-
@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
-
@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:
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!
-
@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)
@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.
. -
@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.
.@AnneRanch
"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.
