[gaza]

Dear Foamers,
According to this guide

https://openfoamwiki.net/index.php/H...or#Usage_hints

in point 3.6.1 we can read
"You can open the header-file (.H) where a class or function was declared by using the tool: Follow symbol under cursor (F2)"
However it does not work for me. Does anybody know how to set up this feature?

[floquation]

I do not know about QtCreator; I like using Eclipse for the same purpose.

In Eclipse, the problem you describe occurs if you do not tell the indexer where the included files are. I reckon the same applies to QtCreator.

Looking at your link, section 3.3 (about Autocomplete) tells you have to specify those locations.

[gaza]

Hi Kevin,
Thank you for your reply. I added lnInclude directories into includes file as described in section 3.3 (about Autocomplete, however it still does not work.

[dplucenio]

Maybe you're still missing some include directories. One thing that helped me on configuring include files was to check on the output of wmake. It will show the command passed on to gcc and anything after -I indicates directories to be included at compilation. I hope this helps

[gaza]

Hi Daniel
So it only depends on includes file?

[dplucenio]

Those outputs I mentioned (You could probably get those from the Make/options files on your project as well, I just though it was easier for me to get them from the wmake output ) are the directories that gcc will need to find the header files your program need to compile. So I think those are also the directories qtcreator needs to find the headers existing on your files. For instance for an application that I'm currently working on these are the directories gcc needs to compile:

-I.
-IlnInclude
-I/home/daniel/Projects/OpenFOAM-dev/src/finiteVolume/lnInclude
-I/home/daniel/Projects/OpenFOAM-dev/src/meshTools/lnInclude
-I/home/daniel/Projects/OpenFOAM-dev/src/
-I/home/daniel/Projects/OpenFOAM-dev/src/OpenFOAM/lnInclude
-I/home/daniel/Projects/OpenFOAM-dev/src/OSspecific/POSIX/lnInclude

So I added at my "project.includes":
.
$$(FOAM_INST_DIR)/OpenFOAM-dev/src/finiteVolume/lnInclude
$$(FOAM_INST_DIR)/OpenFOAM-dev/src/meshTools/lnInclude
$$(FOAM_INST_DIR)/OpenFOAM-dev/src
$$(FOAM_INST_DIR)/OpenFOAM-dev/src/OpenFOAM/lnInclude
$$(FOAM_INST_DIR)/OpenFOAM-dev/src/OSspecific/POSIX/lnInclude
/lnInclude

FOAM_INST_DIR is an environment variable pointing to your openFoam installation directory. If you want to use those, it's a good idea to open qt creator from the terminal session where you have your openFOAM variables set. Let me know if this helped

[gaza]

Unfortunately it does not help.
I would like for example jump to the function

 turbulence->divDevReff(U)

[dplucenio]

Alright, those things that I mentioned would help you on jumping to files. In order to get better autocompletion on qtCreator, one thing that helped me wast to include the header files that has the declarations of the type that i am interested in. The url you linked gives you a hint about that: "Notice that Qt Creator will only be able to autocomplete in files which call the respective definition. OpenFOAM coding style often include standard routines inside the algorithm by #include calls. The compiler accepts this, but it is not a good programming practice. In this case, if you try to edit the routine file createFields.H, you will not have autocompletation of things defined in fvCFD.H. Autocompletation will work only in the file where #include "fvCFD.H" is written."

So what happens is that sometimes the includes on you application (despite it is compiling) do not carry the declaration of the symbol. Maybe the header files that you're currently including only have forward declarations of it, I really don't know. But you need to add the correspondent header file wich carries the declaration of the symbol you're interested in. For instance, in my case to have autocompletion on IOobject type, I had to add #include "OpenFOAM/db/IOobject/IOobject.H" on my .C file.

In your case it seems that you want the header with IncompressibleTurbulenceModel declaration (which has devRhoReff method). Then you would need to add:

#include "TurbulenceModels/incompressible/IncompressibleTurbulenceModel/IncompressibleTurbulenceModel.H"

If you're not having any trouble on compiling it thant it's ok. I had to add

    -I$(LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/incompressible/lnInclude \
    -I$(LIB_SRC)/transportModels \
    -I$(LIB_SRC)/transportModels/incompressible/singlePhaseTransportModel \

on my Make/options but I got qtCreator to autocomplete with IncompressibleTurbulenceModel

[floquation]

Originally Posted by dplucenio

For instance, in my case to have autocompletion on IOobject type, I had to add #include "OpenFOAM/db/IOobject/IOobject.H" on my .C file.

Wait, you are adding #include-s to the actual C-code just to make autocompletion work? That seems very undesirable to say the least.
In Eclipse, I can add include-directories and individual include-files to the indexer's input to achieve that very same purpose. I assume QtCreator has a similar feature?

But yes, you are right in principle. In Eclipse, I also had to include very specific header files to make the turbulence library be recognised by the indexer.

[gaza]

This is my changed includes file, however it still does not jump to divDevReff function

.
#include "/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/TurbulenceModels/incompressible/IncompressibleTurbulenceModel/IncompressibleTurbulenceModel.H"
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/TurbulenceModels/turbulenceModels/lnInclude
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/TurbulenceModels/incompressible/lnInclude
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/transportModels
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/transportModels/incompressible/singlePhaseTransportModel
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/finiteVolume/lnInclude
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/meshTools/lnInclude
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/sampling/lnInclude
/lnInclude
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/OpenFOAM/lnInclude
/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/OSspecific/POSIX/lnInclude

[dplucenio]

Oh, I mean
#include "/home/przemek/OpenFOAM/OpenFOAM-v1606+/src/TurbulenceModels/incompressible/IncompressibleTurbulenceModel/IncompressibleTurbulenceModel.H"

should be added to you aplication .C file. You probably already have

"#include "fvCFD.H" there somewhere. So, try adding

#include "TurbulenceModels/incompressible/IncompressibleTurbulenceModel/IncompressibleTurbulenceModel.H"

In order to get qtcreator to find TurbulenceModels directory, I think you need to add

/home/przemek/OpenFOAM/OpenFOAM-v1606+/src

To your project.include file. This (/home/przemek/OpenFOAM/OpenFOAM-v1606+/src) is always nice to have added so you can easily include anything else you need. You can use https://cpp.openfoam.org to search for the types you're interested in

[dplucenio]

Originally Posted by floquation

Wait, you are adding #include-s to the actual C-code just to make autocompletion work? That seems very undesirable to say the least.
In Eclipse, I can add include-directories and individual include-files to the indexer's input to achieve that very same purpose. I assume QtCreator has a similar feature?

But yes, you are right in principle. In Eclipse, I also had to include very specific header files to make the turbulence library be recognised by the indexer.

As a matter of fact you're right. On qtcreator there's also a "YourProject.files" file where I could add

$$(FOAM_INST_DIR)/OpenFOAM-dev/src/db/IOobject/IOobject.H"

So no need to #include files on my .C source file anymore. Thanks this will be very helpful

[dplucenio]

However, I couldn't see how this would be any disadvantageous at all :/. In fact my take on it is that it's kind of good practice when you're working with C++ and want to use any data type, to add its correspondent header. Say you're using std::vector for instance in your .cpp file but chose not to #include <vector> because you know that a header from a 3rd part library already includes it. Whenever the implementation of this 3rd party library changes, your .cpp will stop compiling.
And this practice also won't add any compile overhead as well, since every .cpp file is compiled independently do generate its object file, the header will be added for sure in order to compile. And thanks to header guards, will be added only once.

[floquation]

Originally Posted by dplucenio

However, I couldn't see how this would be any disadvantageous at all :/. In fact my take on it is that it's kind of good practice when you're working with C++ and want to use any data type, to add its correspondent header. Say you're using std::vector for instance in your .cpp file but chose not to #include <vector> because you know that a header from a 3rd part library already includes it. Whenever the implementation of this 3rd party library changes, your .cpp will stop compiling.
And this practice also won't add any compile overhead as well, since every .cpp file is compiled independently do generate its object file, the header will be added for sure in order to compile. And thanks to header guards, will be added only once.

Your argument makes sense. I'm not experienced enough in C++ to know all best practices and especially the why-s of those practices. So if there are indeed no caveats to it, then yes, you should add them to your own code.
The reason I mentioned what I said in my previous post and the reason I emphasise "to your own code" is that I also use an IDE to read OF's source code, as it allows me to quickly navigate through it. In this case, I still wouldn't consider it a good idea to add #include-s to OF's source code - just to be able to navigate it, especially since there is an alternative that leaves the source code intact.

[Prabs27]

Hello all,

I have read through your discussion and reckoned that there are a few differences between using Qt creator and Eclipse. Can you enlighten me with your experience in general ? I am currently considering to use an IDE for developing a turbine model solver (psioFoamTurbine.ALM.C) of an extended package of OpenFOAM, so indeed the solver is an already modified version of openFOAM solver pisoFOAM.

other primary reasons to choose an IDE over textedit are

1. Find usages of member functions
2. jump to declarations and header files to understand implementations of different formulae

3. Make changes and try to develop my new version.




Regards

Prabhu