Patch for OpenFOAM-dev

[aqeelahmed168]

Hi,

It is possible to have the patch for latest OpenFOAM-dev release.

Is there an automatic way to upgrade the patches based on the new commits that change the settings only for compilation?

[mrklein]

Hi,

I do not know what is the latest OpenFOAM-dev release, I have updated patch for commit 9dc91eb47.

There is no automatic way to update source code tree. Basically, you need to undo previous changes, update sources, and apply new patch. The first can be achieved with git reset --hard <old commit, the second is simple git pull, and final part is just as if you start compilation from the very beginning except you have compiled files, so, if there is no changes in base library, recompilation will be quicker that starting from git clone.

[aqeelahmed168]

Hi, thanks for the patch.

Regarding automation, is it possible to have a function (script) that can look into the build file of any OpenFOAM version and write a patch? It could still use some inputs like the last commit date (etc).

[mrklein]

Hi,

I am not quite sure, I get the idea of automation. Could you elaborate?

[aqeelahmed168]

Hi,

Imagine we have a patch of certain OpenFoam build (like the patch here for the dev version), if we can automatically track the changes in the make file (in all the later commits of the dev branch), then latest available patch could be modified to take into account changes in the build file (using commits from the OpenFoam branch of interest).

It would need to look through all the new commits in the OpenFoam dev branch but could be optimized by some additional filtering.

[mrklein]

It is a bit more complicated. Development branch, for example, likes to break things, so, usually, patches need to be adapted for each new base development. It is simpler for stable versions, where old patches can be applied on a new source tree state.

So, I do not know, how it can be implemented (and whether it should be).

[aqeelahmed168]

If it can be implemented easily on stable versions would be nice addition, since you would not need to make a patch manually.

However, if it will still need manual tuning, then it is not worth the struggle.

Thanks for maintaining this repo anyway.

[staneuski]

Hey! @mrklein, would it be possible to update the dev patch for the current state of the project?

They updated the wmake and broke the patch. I replaced mapfiles in the wmakeLnInclude with a crutch (which seemed as it fixed the issue but I have got missed header error in the later compilation stages anyway):

176,179c176,187
< mapfile -t pruneNames < <(filter name lnInclude Make config noLink)
< mapfile -t prunePaths < <(find .. -mindepth 2 -type d -name Make -printf '%h\n')
< mapfile -t prunePaths < <(filter path "${prunePaths[@]}")
< mapfile -t matchNames < <(filter name '*.[CHh]' '*.[ch]xx' '*.[ch]pp' '*.type')
---
> while IFS= read -r line; do
>     pruneNames+=("$line")
> done < <(filter name lnInclude Make config noLink)
> while IFS= read -r line; do
>     prunePaths+=("$line")
> done < <(find .. -mindepth 2 -type d -name Make -print)
> while IFS= read -r line; do
>     prunePaths+=("$line")
> done < <(filter path "${prunePaths[@]}")
> while IFS= read -r line; do
>     matchNames+=("$line")
> done < <(filter name '*.[CHh]' '*.[ch]xx' '*.[ch]pp' '*.type')

Thanks!

[mrklein]

@StasF1 To avoid problem with incompressibleTwoPhaseVoFMixture.H it is necessary to have two prunePaths arrays with different names. Updated patch in b3f4f2c.

[staneuski]

Great thanks for the patch (it worked for me) and for this repo in general!