#515: Silently overrides DEBUG and OPTIMISE options ----------------------------+----------------------------------------------- Reporter: barry.wardell | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by eschnett):
The option --debug is not about debugging symbols. As you say, there is almost never a reason to run without them, since the don't slow down the code and don't increase memory usage; the only reason to disable them would be if they cause an internal compiler error. What --debug does is enable additional debug statements in the code which perform self-tests and thus lead to a slower execution. Such tests could include checking for integer overflow, checking array bounds in Fortran, etc. What you instead may want to use in your case is --no-optimise, which disables optimisation (without adding these debug statements); this still lets you debug, but runs faster.
Cactus outputs all its configuration settings when it configures, such as "Setting DEBUG to 'yes'". The options --debug, --optimise etc. should be documented, as they are prominent features.
Yes, simfactory overwrites certain settings. Simfactory assumes that the MDB entries are correct, and thus propagates these settings, such as the cache size. The option list and the MDB really belong together and form a unit; it is an "implementation detail" that the option lists are stored in a different file and with a different format.
In general, --debug and --optimise do not conflict. It is just that these don't make sense together, because --debug enables somewhat expensive additional self-checks, and --optimise tries to improve execution speed, so these goals conflict. In practice, many compilers segfault when these two are given together. To protect new users, the default for --optimise depends on the setting for --debug. It seems that the current implementation in simfactory doesn't quite do that, as it unconditionally sets --optimise when --debug is set. (--optimise isn't quite useless, because you can still specify --no-optimise.)
Enabling --debug by default on a particular machine goes a bit against the idea of simfactory, which is to make things independent on particular machines. I envisioned that you have probably two configurations, one for debugging and one for production, and these configurations would both potentially exist on multiple machines. This allows you e.g. to take a debug session from your laptop and move on to a larger workstation if you run out of memory; for this to work reliably, the configuration settings (source tree, thorn list, etc.) need to be independent of the machine on which one is running. This is the working model that "sim sync" enables. That is, you would choose two configuration names (maybe "sim-debug" and "sim") for these two purposes, and sync/build these on several systems. To build the debug configuration, you say "sim build --debug", and "sim build" to build the production simulation; as described in <https://docs.einsteintoolkit.org/et- docs/Simulation_Factory_Advanced_Tutorial>.
Your second patch is fine, please apply.