another "include" question...

[MarkTJohnson]

single dot is the current directory, double dots are one level UP (closer to the root directory) from where you are. So backtrack to the root and then go down the correct path.

I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.

[jschell]

MarkTJohnson wrote:

single dot is the current directory

However that refers to the execution directory. Which might not be what one expects.

[jschell]

Adding to what the other reply said.

Salvatore Terress wrote:

-L$$OUT_PWD/../../../CCC_SOURCE/BT_Utility_Library/ -lBT_Utility_Library

In that '$OUT_PWD' is a directory. Then each '..' moves UP the directory tree. So it moves up three levels. Then it expects to find CCC_SOURCE Whether it does so depends on whether '$OUT_PWD' is set to a correct value. This can be further complicated by whether '$OUT_PWD' is a full directory or a partial directory. So if it is something like './MyStuff/Programs' (where the dot is important) then it is a partial directory. But if there is no dot then it is a full directory that must exist at the root of your file system.

[Lost User]

Each double dot means move up to the parent of the current directory. The variable $$PWD will refer to the current directory, when this statement is processed. So assuming a project tree like:

home
-- terress
-- dev
-- myproject
-- btsamples
-- test -> assume this is $PWD

then the above statement will expect to find BT_Utility_Library in a directory named CCC_SOURCE in /home/terress/dev.

[k5054]

To add to what the others have said, the same convention is used in Windows as well. At the command line, if you type cd ..\.. you move up 2 folders from the current one (assuming that you're at least 2 levels deep).

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

[Lost User]

Update / followup This is how .pro (QT project file) is "linked" to libraries. OK

unix:!macx: LIBS += -L$$OUT_PWD/../BT_LIBRARY/CCC_SOURCE/BT_Utility_Library/ -lBT_Utility_Library

INCLUDEPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/BT_Utility_Library
DEPENDPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/BT_Utility_Library

unix:!macx: LIBS += -L$$OUT_PWD/../BT_LIBRARY/CCC_SOURCE/TEST_DIALOG/untitled_TEST/ -luntitled_TEST

INCLUDEPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/TEST_DIALOG/untitled_TEST
DEPENDPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/TEST_DIALOG/untitled_TEST

These are header files

#include "bt_utility_library.h"
#include "BT_Utility_Library_global.h"

#include "../untitled_TEST/mainwindow_test_dialog.h"

the mainwindow_test_dialog.h is liked "one up " and then use "subproject"...level So my question remains are linking library project "path" NOT related to linking "include " path ?

[Lost User]

Salvatore Terress wrote:

are linking library project "path" NOT related to linking "include " path ?

They are linked in the sense that both are required to build your application, but in another sense they are totally separate. Header files are used by the compiler to generate correct calling code to external class methods and functions, but with the actual addresses of the function incomplete. Library files are in two parts. The first are required by the linker phase to provide the actual addresses of the external methods and functions. The linker calculates the real addresses and plugs them into your code so all the calls actually work. The second part, the code in the library files that does the work, can be in one of two places. Firstly it may be in a simple archive (.a type) that is built into your application by the linker, and loaded with it when it runs. Secondly, it can be in a shared object file (.so type) which is loaded into memory when required by the operating system. So it does not matter where these files are when you are building your project, only that the compiler and linker can find them when required.

[Maximilien]

Salvatore Terress wrote:

I will freely admit that I have newer mastered "../.." - whatever it is called -

It's called a relative path. it's used instead of using an absolute path; makes the code more portable by not fixing a hard-coded absolute path. [What are the differences between absolute and relative paths? | Enable Sysadmin](https://www.redhat.com/sysadmin/linux-path-absolute-relative)

CI/CD = Continuous Impediment/Continuous Despair

[Lost User]

Nice explanation, thanks. I need to come up with "flow chart" how QT project actually use the "include this " - the lowest level would be C code ... ( what to call this - it will be part or QR .pro (project) file / folder ) header ( declaration ) code (definition )

[Lost User]

The project does not "use the include files". They are putely source code definitions and declarations used by the compiler to build the object file. What hapens in reality is the the compiler reads every file that is (directly or indirectly) named in an #include statement, and builds a new source file that comprises your source code plus all the included text. It then processes that source to create the object file. Each separate object file will then be used as input to the linker, along with all referenced libraries to build the final executable.