New Build System #791
New Build System #791
Conversation
|
I decided that I'll fight with tl;dr: We have two options:
I'm strongly in favour of 2. I think these runs have flagged some genuine issues that are worth fixing now rather than sweeping back under a rug of compiler options. Or maybe some of these are fixed on Regarding those issues, they actually fall into some large categories.
The remaining tests ( |
|
Also probably worth mentioning that this is a continuation of this original external PR (#724). |
This commit introduces a new build system (still based on make files). Reasons for replacing the previous build system were: - the previous build system had a lot of duplication between the modules, both in terms of make files and shell scripts. - parallelisation was limited. The new build system parallelises better within a module, and between modules. - build scripts and output from the build ended up in the same folder. With the new system, all build output files are stored in the folder ``build`` in the repository root, making cleaning build files equivalent to deleting this folder For the details of the implementation, see the newly added documentation (Developing -> Build system). Some further notable changes: - makedepf90 has been replaced by a perl script that scans the fortran source files. This allows for better flexibility in construction the make files. - Currently, `pymesa` does not work with the new build system, as the new system does not provide a way to build shared libraries for every module. - Dependencies are being discovered using pkg-config. This change makes it easier to build MESA without the SDK, as linux distributions typically ship with pkg-config files.
This commit adds the necessary pkg-config files until the SDK ships them.
Plotter does not work with default inlist (and encounters NaNs in eos)
Work directories require a bit more massaging to work: - The compilation of the work directory needs to be able to find the compiled artefacts in the main mesa build directory, but store its own output in the build directory in the work directory. This is accomplished by keeping the main build directory pointed to the MESA directory, and only set BUILD_DIRECTORY_MODULE to the work dir build directory, as only this one is used for the generated files. - The binary module needs to refer to sources in the MESA directory. this is because these sources cannot be compiled in during the installation, as they depend on functions in the work directory sources. From a user perspective, the main changes are: - The removal of the `clean` and `mk` scripts. These are replaced by `make clean` and `make` respectively. - The star executable will always be built before it is ran. This will eliminate issues where the one forgets to rebuild the executable.
Otherwise one could get warnings from the compiler
…arlier versions of MESA
How to actually use the preprocessor is left as an exercise to the reader. This is to make the bit-rot not be worse than it already is.
fecf573 to
971fa3c
Compare
|
I have rebased on main cleaned up some things (e.g. extracted #808). There are some test cases which run into issues. From what I could see running tests locally (i.e. without checksums), the ccsn, all rsp tests, and all adipls tests fail with FPEs. While these can easily be fixed by initializing certain variables to zero at somewhat arbitrary points, it doesn't feel like a clean solution. Moreover, adipls is not failing on some uninitialized variable, but on an actual divide by zero. I actually prefer going for option one, I have added a commit that disables FPEs by default. Syncing this PR with main was rather painful, so I would rather see this merged sooner than later (as long as there are no outstanding issues of course). Since the option to enabled FPEs still exists, getting the tests/other parts of MESA to cooperate can still be done in the future. I am running the test suite on the local cluster with the latest changes, and I'll see whether any other issues crop up. This is without the checksums, since they are not in the repository. |
|
Something I forgot to add is that the default insertion of NaNs could have also been a reason for the difference in the photos. |
ccbe028 to
d248833
Compare
This suppresses uninitialized warnings, and in some cases, variables containing garbage instead of zero is load bearing.
by Vincent Vanlaer