wmake problem with header
Hi!
I am trying to follow this simple procedure to add temperature solving to icoFoam, as outlined here; https://openfoamwiki.net/index.php/H...ure_to_icoFoam When I try to do wmake (before any changes to the code, other than renaming files), I get the following error: Code:
/home/user/OpenFOAM/OpenFoam-v2106/src/OpenFOAM/lnInclude/face.H:52:11: fatal error: surfacePatchList.H: No such file or directory Do you have any idea what is going on here? |
I recompiled OpenFoam with all dependencies, and now it seems to work. (Still don't know why, though.)
|
At times it is valuable to distinguish between OpenFoam (specific) and C++ (more general).
In compiling C++ (and other languages) code one distinguishes between compiling (typically using compiler with -c option) to obtain object code (*.o file) and linking to obtain executable. The error you point out refers to the compile stage. The compiler does not find the header (*.H) file because you haver not told the compiler where (which directory) the header file is located using the -I option. You can look into C++ tutorials to convince yourself. |
1 Attachment(s)
Quote:
The files cannot be found, which usually happens if your changes have somehow bypassed the regular wmake mechanism. The wmakeLnInclude script is one of the helpers you are looking for. The longer explanation: the OpenFOAM code hierarchy for each src/... directory is flattened out into a single "lnInclude" directory of symlinked files. This makes it much easier to handle since the code can then simply include the header without specifying the subdirectory path, or without adding loads of different include directories into the compilation line. When compiling a "libso" target, the wmake scripts will generate and populate the lnInclude directory with symlinks. If header files are added or moved later, it can be that they are missing from the "lnInclude" and you will have to address that yourself. Here is what I normally do. - Determine where the file is really located. It certainly helps if you have git installed, but the 'find' command will also work (but slower). Here is the git approach (I do it frequently enough that I actually have a git-find script with a few more options). Code:
$ cd $WM_PROJECT_DIR - use wmakeLnInclude to (re)create the corresponding symlinks. Code:
$ cd src/surfMesh # This is what we found in the previous step Code:
$ cd src/surfMesh/triSurface/patches # location of the header file Side-note: sometimes if you juggle the contents of the headers and remove some included files the dependency check can get a bit wrecked (ie, it tries to check if a now nonexistent file is up-to-date). For these cases you can use the `wrmdep` to remove the old, dirty dependency file. In some cases, however, it can be useful to replace the removed file with a dummy stub such as provided in `etc/codeTemplates/removed-file`: Code:
#warning File removed - left for old dependency check only I hope that this answers more questions than it raises. |
Thanks a lot for your answer!
This does explain a lot. And it shows that I do not at all know as much as I would like to about the architecture of complex software and how it is managed and compiled. I usually type 'wmake' or some other code snippet I copied from somewhere and cross my fingers. I feel like a blind man when I stumble upon these sorts of errors - but thanks for shedding a little light. |
All times are GMT -4. The time now is 12:09. |