Meson build system
Hello,
in this issue, we talked about exploring meson as an alternate build system. The first prototype is ready and can be found here. The build currently works like that:
$ ./generate_lnInclude.py
$ ./generate_meson_build.py
$ /path/to/the/correct/version/of/meson.py setup your_build_directory
$ ninja -C your_build_directory
the ./generate_meson_build.py
command requires the OpenFOAM environment to be set, the other 3 commands don't.
Note that you currently need this version of meson. I will work to get that merged into the original meson.
Please don't forget that this is just the first prototype. Today is literally the first day that it builds on my machine without Allwmake being run prior. So don't suggest things that are obvious like "you forgot the add the license notes in some files" or "you still have some todo comments" or "you need to cleanup the code". Please only suggest non-obvious things. If the build does not work on your machine, it is probably because the dependency lookup of things like scotch or metis or kahip is only tested for my machine.
generate_lnInclude.py
makes symlinks into lnInclude directories and generate_meson_build.py
is a very hacky script that creates the meson.build
files.
If we like this Prototype and we decide to continue working on meson I will remove the necessity for generate_lnInclude.py
. We would ship the meson.build files, so generate_meson_build.py
would be either never run, or only run by build-system developers.
If running generate_meson_build.py
does not work on your machine or you want to look at the results without having to setup everything, this patch are the generated meson.build files.
Before you do performance tests of meson vs wmake, you should note that we currently link some things a bit different than wmake, so linking will get faster.
What I like about this meson/prototype:
-
Meson is far better at knowing if something needs to be rebuild or not. If you forget to add a file to Make/files, but you include that file,
wmake
will not rebuild your code if you change this file. if you change a meson.build file, meson will rebuild all targets affected by the changes, but not rebuild the other targets. -
Unlike wmake, meson is used by a lot of other projects. This means better tooling support, better community support and better documentation. It also means newcomers to the projects might already know meson.
-
If everything is up to date, ./Allwmake takes a long time, but
ninja
takes less than a second if everything is up to date. -
The meson.build files are really easy to read, no comparison the the wmake folder that has bash scripts and hard to read makefiles. For an outsider, it is far easier to read those meson.build files and understand than, than to read and understand the root/wmake folder. The only part complicated thing in the meson.build files are the two topological sorts at the bottom of root/meson.build (the
foreach step : [1,1,1,1,1,1,1,1,1,1,1,1,1,1,0]
loops). Note that I'm currently working on getting this algorithm into the meson master branch (see https://github.com/mesonbuild/meson/issues/8178).
What do you think of this prototype?
Activity
- Volker Weißmann changed the description
changed the description
- Volker Weißmann mentioned in issue #1936 (closed)
mentioned in issue #1936 (closed)
- Author
@mark Do you know when you will look at the prototype? It would be nice if I would know, whether I should continue working on it or not. The next goal would probably be to get https://clang.llvm.org/docs/AddressSanitizer.html to work.
- Maintainer
Hi @volker-weissmann - not sure when I'll find time, needing to patch together a meson version is certainly a bit of a time hurdle and would certainly preclude actually shipping to use it. But meson meson on its own isn't directly the interesting part for me. More interesting is harnessing it for ninja builds.
Nonetheless, if you can take some time to examine the marginal corner cases with our Make/{files,options}. For example, take a look at the
src/Allwmake
file lines 28-45. There you will find some ad hoc handling of linking Pstream/OpenFOAM using a double pass for mingw cross-compilation. Another example isapplications/surface/surfaceBooleanFeatures/Allwmake
and the corresponding Make/{files,options}. These are the types of things you will also need to keep in mind when developing your adaptor layer, otherwise it will be of very limited usefulness.For the clang address sanitizer, probably better to either spin off a compilation mode (eg, Sanitize) by copying the wmake c++Opt -> c++Sanitize rule and adding the extra flags under the c++DBUG entry (cf. upgrade entry). But the simplest is just to use the
FOAM_EXTRA_CXXFLAGS
variable when calling. - Author
would certainly preclude actually shipping to use it.
I would propose the following: I improve the meson build. After that, we add the meson build files to this repo (and maybe backport it to Openfoam8 or Openfoam7) and write on the readme/website/wiki : You can build it either with
./Allwmake
or (experimental) withmeson setup builddir && ninja -C builddir
. That way we can see how it performes in the real world.But meson meson on its own isn't directly the interesting part for me. More interesting is harnessing it for ninja builds.
?? What do you mean "harnessing" it for ninja builds? Using ninja without meson is a bad idea.
Nonetheless, if you can take some time to examine the marginal corner cases with our Make/{files,options} ...
Yes, I can do that. I already discovered some of those things. Most of it is currently hardcoded for my machine.
For the clang address sanitizer ...
Yes, I know that that would work, but if we want to use meson seriously, than it should support such stuff.
- Maintainer
Hi @volker-weissmann What I mean about meson is that we need to be clear about the cost/benefit of all parts of any solution if we want to replace a working system (ugly or otherwise) with a newer one. The main thing that I find interesting is testing/using ninja for the builds. It is becoming more widespread, which is always a must. As soon as python is involved I start to be concerned about portability/availability, which is why I would prefer to focus on the end result (ninja build) instead of the how (meson) since I know from experience that this will take time to mature for us.
I have pulled across your commits from your 'meson3' branch. Could you please fix these bits:
- 4 spaces for indentation, no tabs. We do not use tabs.
- no trailing space in code files. Avoids spurious (and noisy) file changes.
- use standard paths. The path
/bin/python
is non-standard. I don't know which systems it may exist on, but certainly not on suse or redhat. - If the code only works with python2 or python3, need to state that somewhere. Or avoid expressions that are sensitive to the version 2/3 change (if that it possible).
- don't pollute the etc/ directory with executable scripts such as
etc/m4lemon.sh
. This looks largely like whatwmake/scripts/wrap-lemon
already covers. It certainly is not an etc config file or setup. - the generate_meson_build script has "mainsrc" embedded as a string? This cannot be correct. Maybe you need to create a sensible place for the stuff (eg,
wmake/meson/
) where you can sensibly keep script fragments and helper routines without scattering them all over. At least until things get finalized. - if possible, check that it works on a second system and/or a second installation directory. To ensure we don't have hard-code paths lurking.
- if every thing gets dumped into a wmake/meson directory, then at least all of the RPM, Ubuntu, spack and EasyBuild packaging scripts will not instantly. This may not seem important, but trying to maintain separate packaging logic in four different places needs to be well considered. I generally try to package for the last few versions (currently the 1912 version is the oldest that I still package), so bad choices will be painful for quite a while.
First failure (after changing /bin/python to /usr/bin/python) :
Traceback (most recent call last): File "./generate_meson_build.py", line 14, in <module> from meson_codegen import * File "/home/mol/openfoam/OpenFOAM-com/meson_codegen.py", line 81 print(" "*(firstlineindent+13), end="")
Beyond that, I don't want to be discouraging, but make sure that your efforts will pay off sooner rather than later.
Edited by Mark OLESEN - Author
As soon as python is involved I start to be concerned about portability/availability,
Isn't python available pretty much everywhere?
As to your "could you fix these bits". As I said, it is very much in development. What you proposed is called "cleanup" and I will do that once I have solved all of the main problems. I'm not stupid, I also knew most of what you said. After cleanup is done, I will squash it into a few single commits.
Traceback (most recent call last): File "./generate_meson_build.py", line 14, in from meson_codegen import * File "/home/mol/openfoam/OpenFOAM-com/meson_codegen.py", line 81 print(" "*(firstlineindent+13), end="")
First of all, I think you cut of the last line of this exception.
If you want a working script, use ab634e3e6439d9cec7507df10c85e20cad25864e
Beyond that, I don't want to be discouraging, but make sure that your efforts will pay off sooner rather than later.
Sure. I hope that it is ready for the first merge in maybe two weeks?
Edited by Volker Weißmann - Maintainer
bash: ./generate_meson_build.py: /bin/python: bad interpreter: No such file or directory
- Author
I will fix that part, but I meant that python can be installed on nearly every system.
- Maintainer
Isn't python available pretty much everywhere?
Not really. Often yes, but then you don't know which version you get or if you have conflicts with what your environment modules happened to send your way.
As to your "could you fix these bits". As I said, it is very much in development. What you proposed is called "cleanup" and I will do that once I have solved all of the main problems. I'm not stupid, I also knew most of what you said. After cleanup is done, I will squash it into a few single commits.
OK, good to know that you will adjust to accommodate our coding standards, but usually easier to do before too much code gets generated unless there is a cool code-reformatting that you can use.
Im Übrigens, damit habe ich nicht andeuten wollen, das irgendjemanden blöd wäre. Bloß versucht die Erwartungshaltung klar zu formuliert, um künftige Missverständnisse aus dem Weg zu räumen und unnötige Überarbeitungen zu vermeiden. Dass die Punkten schnörkellos formuliert sind, ist mal so. Keine Unhöflichkeit war damit gemeint. Und sorry, falls es so geklungen hat.
- Please register or sign in to reply
- Maintainer
Are these normal work-in-progress errors, or more fundamental?
warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists ('warning:', u'./applications/solvers/heatTransfer/chtMultiRegionFoam/Make/.././porousFluid', 'does not exist') ('warning:', u'./applications/solvers/heatTransfer/chtMultiRegionFoam/Make/.././porousSolid', 'does not exist') warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists warning, path does not exists ('warning:', u'./applications/solvers/stressAnalysis/solidEquilibriumDisplacementFoam/Make/../tractionDisplacementCorrectionStress', 'does not exist') warning, path does not exists warning, path does not exists warning, path does not exists ('warning: not starting with -l: ', u'-L../../../platforms/linux64GccDPInt32Opt/lib/dummy') warning, path does not exists ('warning:', u'./applications/test/parallel-external-init/Make/..//usr/lib64/mpi/gcc/openmpi2/include', 'does not exist') ('warning: not starting with -l: ', u'-pthread') ('warning: not starting with -l: ', u'-L/usr/lib64/mpi/gcc/openmpi2/lib64') warning, path does not exists warning, path does not exists ('warning:', u'./applications/utilities/mesh/generation/foamyMesh/conformalVoronoiMesh/Make/..//home/mol/openfoam/ThirdParty-common/platforms/linux64Clang110/boost_1_66_0/include', 'does not exist') ('warning:', u'./applications/utilities/mesh/generation/foamyMesh/conformalVoronoiMesh/Make/..//home/mol/openfoam/ThirdParty-common/platforms/linux64Clang110/CGAL-4.12.2/include', 'does not exist') ('warning: not starting with -l: ', u'-L/home/mol/openfoam/ThirdParty-common/platforms/linux64Clang110/boost_1_66_0/lib') ('warning: not starting with -l: ', u'-L/home/mol/openfoam/ThirdParty-common/platforms/linux64Clang110/boost_1_66_0/lib64') ('warning: not starting with -l: ', u'-L/home/mol/openfoam/ThirdParty-common/platforms/linux64Clang110/CGAL-4.12.2/lib') ('warning: not starting with -l: ', u'-L/home/mol/openfoam/ThirdParty-common/platforms/linux64Clang110/CGAL-4.12.2/lib64') ('warning: not starting with -l: ', u'-L../../../../../platforms/linux64GccDPInt32Opt/lib/dummy') ('warning: not starting with -l: ', u'-L../../../../../platforms/linux64GccDPInt32Opt/lib/dummy') ('warning: not starting with -l: ', u'-L../../../../platforms/linux64GccDPInt32Opt/lib/dummy') ('warning: not starting with -l: ', u'-L../../../../platforms/linux64GccDPInt32Opt/lib/dummy') warning, path does not exists warning, path does not exists warning, path does not exists ('warning:', u'./applications/utilities/preProcessing/wallFunctionTable/tabulatedWallFunction/Make/../../../../../../src/turbulenceModels', 'does not exist') warning, path does not exists warning, path does not exists ('unable to parse:', './applications/utilities/preProcessing/PDR/pdrFields/Make', 'AssertionError(u"pdrFields--------------./applications/utilities/preProcessing/PDR/pdrFields/Make--------{u\'helpTypes\': \'./applications/utilities/miscellaneous/foamHelp/helpTypes/Make\', u\'testFunctionObjects\': \'./applications/test/testFunctionObjects/Make\', u\'multiphaseInterFoam\': \'./applications/solvers/multiphase/multiphaseInterFoam/multiphaseMixture/Make\', u\'driftFluxRelativeVelocityModels\': \'./applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/Make\', u\'phaseTemperatureChangeTwoPhaseMixtures\': \'./applications/solvers/multiphase/interCondensatingEvaporatingFoam/temperaturePhaseChangeTwoPhaseMixtures/Make\', u\'laserDTRM\': \'./applications/solvers/multiphase/icoReactingMultiphaseInterFoam/laserDTRM/Make\', u\'cv2DMesh\': \'./applications/utilities/mesh/generation/foamyMesh/conformalVoronoi2DMesh/Make\', u\'multiphaseMixtureThermo\': \'./applications/solvers/multiphase/compressibleMultiphaseInterFoam/multiphaseMixtureThermo/Make\', u\'VoFphaseCompressibleTurbulenceModels\': \'./applications/solvers/multiphase/compressibleInterFoam/VoFphaseCompressibleTurbulenceModels/Make\', u\'alphaFieldFunctions\': \'./applications/utilities/preProcessing/setAlphaField/alphaFieldFunctions/Make\', u\'tabulatedWallFunctions\': \'./applications/utilities/preProcessing/wallFunctionTable/tabulatedWallFunction/Make\', u\'phaseChangeTwoPhaseMixtures\': \'./applications/solvers/multiphase/interPhaseChangeFoam/phaseChangeTwoPhaseMixtures/Make\', u\'rhoCentralFoam\': \'./applications/solvers/compressible/rhoCentralFoam/BCs/Make\', u\'pdrFields\': \'./applications/utilities/preProcessing/PDRsetFields.orig/PDRsetFields/pdrFields/Make\', u\'driftFluxTransportModels\': \'./applications/solvers/multiphase/driftFluxFoam/mixtureViscosityModels/Make\', u\'compressibleTwoPhaseMixtureTurbulenceModels\': \'./applications/solvers/multiphase/MPPICInterFoam/compressibleTwoPhaseMixtureTurbulenceModels/Make\', u\'twoPhaseSurfaceTension\': \'./applications/solvers/multiphase/compressibleInterFoam/surfaceTensionModels/Make\', u\'conformalVoronoiMesh\': \'./applications/utilities/mesh/generation/foamyMesh/conformalVoronoiMesh/Make\', u\'extrude2DMesh\': \'./applications/utilities/mesh/generation/extrude2DMesh/extrude2DMesh/Make\', u\'twoPhaseMixtureThermo\': \'./applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo/Make\', u\'DPMTurbulenceModels\': \'./applications/solvers/lagrangian/DPMFoam/DPMTurbulenceModels/Make\'}",)') Traceback (most recent call last): File "./generate_meson_build.py", line 485, in <module> scan_path(".", 1) File "./generate_meson_build.py", line 54, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 54, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 54, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 54, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 54, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 82, in scan_path mesonsrc = mesonsrc + wmake_to_meson(path.join(dirpath, "Make"), stage) File "./generate_meson_build.py", line 328, in wmake_to_meson raise ex AssertionError: pdrFields--------------./applications/utilities/preProcessing/PDR/pdrFields/Make--------{u'helpTypes': './applications/utilities/miscellaneous/foamHelp/helpTypes/Make', u'testFunctionObjects': './applications/test/testFunctionObjects/Make', u'multiphaseInterFoam': './applications/solvers/multiphase/multiphaseInterFoam/multiphaseMixture/Make', u'driftFluxRelativeVelocityModels': './applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/Make', u'phaseTemperatureChangeTwoPhaseMixtures': './applications/solvers/multiphase/interCondensatingEvaporatingFoam/temperaturePhaseChangeTwoPhaseMixtures/Make', u'laserDTRM': './applications/solvers/multiphase/icoReactingMultiphaseInterFoam/laserDTRM/Make', u'cv2DMesh': './applications/utilities/mesh/generation/foamyMesh/conformalVoronoi2DMesh/Make', u'multiphaseMixtureThermo': './applications/solvers/multiphase/compressibleMultiphaseInterFoam/multiphaseMixtureThermo/Make', u'VoFphaseCompressibleTurbulenceModels': './applications/solvers/multiphase/compressibleInterFoam/VoFphaseCompressibleTurbulenceModels/Make', u'alphaFieldFunctions': './applications/utilities/preProcessing/setAlphaField/alphaFieldFunctions/Make', u'tabulatedWallFunctions': './applications/utilities/preProcessing/wallFunctionTable/tabulatedWallFunction/Make', u'phaseChangeTwoPhaseMixtures': './applications/solvers/multiphase/interPhaseChangeFoam/phaseChangeTwoPhaseMixtures/Make', u'rhoCentralFoam': './applications/solvers/compressible/rhoCentralFoam/BCs/Make', u'pdrFields': './applications/utilities/preProcessing/PDRsetFields.orig/PDRsetFields/pdrFields/Make', u'driftFluxTransportModels': './applications/solvers/multiphase/driftFluxFoam/mixtureViscosityModels/Make', u'compressibleTwoPhaseMixtureTurbulenceModels': './applications/solvers/multiphase/MPPICInterFoam/compressibleTwoPhaseMixtureTurbulenceModels/Make', u'twoPhaseSurfaceTension': './applications/solvers/multiphase/compressibleInterFoam/surfaceTensionModels/Make', u'conformalVoronoiMesh': './applications/utilities/mesh/generation/foamyMesh/conformalVoronoiMesh/Make', u'extrude2DMesh': './applications/utilities/mesh/generation/extrude2DMesh/extrude2DMesh/Make', u'twoPhaseMixtureThermo': './applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo/Make', u'DPMTurbulenceModels': './applications/solvers/lagrangian/DPMFoam/DPMTurbulenceModels/Make'}
- Author
- Most of these "
warning, path does not exists
" happen because some Make/options files have-I/path/to/nonexsting/directory
in them. - Most of these warnings are in deed work in progress warnings, they also happen on my machine.
- I use Python3 and I don't intend to ever make it Python2 compatbible. If the meson.build files are commit into the repo, only a few developers will ever have to run this script.
- About that assertion. It means that generate_meson_build.py parsed code describing how to build "libpdrField.so" twice. It does not happen on my machine. This assertion should not matter that much, because that part will be changed anyway, so you don't need to debug it. If you want to test the rest, you can either remove this assertion or use the
https://develop.openfoam.com/Development/openfoam/uploads/5ec388bb5375f241daf0142e958aedbe/meson_build.patch
.
- Most of these "
- Maintainer
I will fix that part, but I meant that python can be installed on nearly every system.
Sure it can be installed on every system, but better if we can avoid adding more build prerequisites than absolutely necessary. If python is not installed, then the cascade of questions come: will the admin install it? can the user install in their own workspace? (are they capable, does this conform to local system policy, does it harmonize with other installed components).
This type of consideration was one of the factors that pushed us towards using lemon instead of bison in addition to other considerations. Berhard Gschaider has had many painful experiences with that part of swak4foam. Broken installations, old (unusable) versions, some intermediate incompatibilities etc. The same thing afflicted us with Flex a few years back. CentOS-4 was still shipping with a 1997 version if I remember correctly.
- Author
Not really. Often yes, but then you don't know which version you get or if you have conflicts with what your environment modules happened to send your way.
Sure it can be installed on every system, but better if we can avoid adding more build prerequisites than absolutely necessary.
Easy solution:
generate_meson_build.py
is not part of the build system. If the meson.build files are committed into the repo, you don't have to rungenerate_meson_build.py
to build it.generate_meson_build.py
is as much a build dependency as emacs is, because I use that for coding does not mean other people have to.generate_meson_build.py
will probably be in bin/tools. If this script does not run on someones machine, this is fine.The point is that the output of
generate_meson_build.py
is independent of the machine (at least it should be). This means that you can rungenerate_meson_build.py
. The generated meson.build files are very easy to read and to change by hand. IMHO, they are far easier to read and understand than the contents of the wmake folder and the Allwmake scripts and most other build systems.Note that this only works, because the output of
generate_meson_build.py
is machine independent, unlike the output of meson, which is machine dependent.The only situation where you have to rerun it, is if you want to do some large scale change to the build system. And if you want to do that, installing python should not be a hurdle. It won't run on servers, it will run on the developer machine.
That is why you should not check if
generate_meson_build.py
is nicely written, but if themeson.build
files are nicely written (I think they are). Just imagine if I had created a PR, with just this patchNote that future versions of
generate_meson_build.py
will require Python 3.9 because of graphlib.OK, good to know that you will adjust to accommodate our coding standards, but usually easier to do before too much code gets generated unless there is a cool code-reformatting that you can use.
Emacs
M-x untabify
converts tab to spaces.Im Übrigens, damit habe ich nicht andeuten wollen, das irgendjemanden blöd wäre. Bloß versucht die Erwartungshaltung klar zu formuliert, um künftige Missverständnisse aus dem Weg zu räumen und unnötige Überarbeitungen zu vermeiden. Dass die Punkten schnörkellos formuliert sind, ist mal so. Keine Unhöflichkeit war damit gemeint. Und sorry, falls es so geklungen hat.
Du musst dich nicht entschuldigen, ich bin nicht so empfindlich. Da wo ich herkomme hat man ganz andere Definitionen von höflich und unhöflich, da nennt man alles was man keine drei Häuser weiter hört höflich.
- Maintainer
src/OSspecific - or does this get done elsewhere?
- Author
What do you mean?
Currently, these meson.build files only work on POSIX, but I windows support will soon follow. At the end, we will have something like
if target_machine.system() == "windows" subdir('MSwindows') else subdir('POSIX') endif
in
src/OSspecific/meson.build
Edited by Volker Weißmann - Maintainer
No meson.build anywhere under src/OSspecific, but then again I'm working from your commit d2bc2cc11b4113df83402a1951718ab1a6b363e8. Couldn't find the referenced upload.
- Author
This patch does include a src/OSspecific/meson.build file:
- Maintainer
I wanted to generate my own.
- Author
I think its best if you use the newly pushed 42e9478a4415d3c55e1dc614809d4362a93d07fc Note that the whole
Template
andBuildDesc
classes are currently not in real use. - Maintainer
I have picked across from "first prototype" to "should work now".
./$ ./generate_meson_build.py Traceback (most recent call last): File "./generate_meson_build.py", line 552, in <module> scan_path(".", 1) File "./generate_meson_build.py", line 56, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 56, in scan_path hasmake = scan_path(tot, stage) File "./generate_meson_build.py", line 56, in scan_path hasmake = scan_path(tot, stage) [Previous line repeated 1 more time] File "./generate_meson_build.py", line 84, in scan_path mesonsrc = mesonsrc + wmake_to_meson(path.join(dirpath, "Make"), stage) File "./generate_meson_build.py", line 385, in wmake_to_meson template.make_absolute(PROJECT_ROOT / thisdir) File "/home/mark/openfoam/OpenFOAM-com/meson_codegen.py", line 407, in make_absolute self.temp = self.regex.sub(file_matcher, self.temp) File "/home/mark/openfoam/OpenFOAM-com/meson_codegen.py", line 403, in file_matcher assert os.path.exists(abs) AssertionError
- Author
I have picked across from "first prototype" to "should work now".
I'm sorry.
ROOT_PATH = "/home/volker/Sync/git/openfoam"
This is the line you need to update.
- Maintainer
commented out line 305 etc (the assert), get further. How can I block directories? It fails while scanning the avalanche module:
AssertionError: $(FOAM_MODULE_APPBIN)/releaseAreaMapping ----- $(PWD)/
- Author
Yes, Line 63-83 is used for commenting out nonwirking directories is used
Edited by Volker Weißmann - Author
But I'm still surprised that it does not work on your machine. It should not be very machine dependent. Are you using it on the openfoam source tree of my repo or on the master branch? Does
make --version
outputGNU Make ...
.Is the order of
for el in listdir(dirpath):
nondeterministic?Edited by Volker Weißmann - Maintainer
Make is
GNU Make 4.2.1 Built for x86_64-suse-linux-gnu
I don't use your repo branch, but rebased your 'meson3' onto a current develop. Your "master" branch was split off of a v2006 maintenance, so it is less useful for the current version. It probably also explains the pdrFields failure. That got refactored into a library, which seems to trip up your script.
Consider master and develop to be reserved branch names. The master branch only receives bugfixes and config adjustments. See the branch descriptions.
Thus your branch should be called something like 'meson-build' as feature branch. As a feature branch, an arbitrary rebase and forced update is permissible. This means that you should rebase onto the lastest master or develop (your choice) to ensure that we have a similar setup. During the rebase, please remove the src/OpenFOAM/global/global.cpp file. This type of generated file should not belong in the repo.
Edited by Mark OLESEN
- Author
I don't use your repo branch, but rebased your 'meson3' onto a current develop. Your "master" branch was split off of a v2006 maintenance, so it is less useful for the current version. It probably also explains the pdrFields failure. That got refactored into a library, which seems to trip up your script.
That explains a lot
This means that you should rebase onto the lastest master or develop (your choice) to ensure that we have a similar setup.
WiP
During the rebase, please remove the src/OpenFOAM/global/global.cpp file.
WiP
- Volker Weißmann mentioned in issue #2520
mentioned in issue #2520
- Author
@mark Is there a reason why you are using scotch-6 instead of scotch-7?
- Developer
As mentioned by Mark, we had issues with 6.1.2 during update of v2112 Refer GL#2254
Scotch - 7.0.1 gave error while compilation on Gcc-4.8.5 as below
We Skipped interim version as likely they might have issues as well.
- Maintainer
6.1.2 had issues with dgraph (distributed graph). Can't remember what was wrong with scotch-7 on older compilers. @Prashant ?
- Volker Weißmann mentioned in issue #2718
mentioned in issue #2718