…s, and algebraic variables.

…d algebraic variables for initialiseVariables().

…d algebraic variables for computeRates().

…d algebraic variables for computeVariables().

…d algebraic variables for computeComputedConstants().

To do it manually is very time consuming while here it gets done automatically. From there, we can quickly confirm, using git, whether the new expected file contents is correct.

…tants, and algebraic arrays.

… an equation.

We will also need to keep track of states and constants.

…xternal variables.

…AIC_INFO, and EXTERNAL_INFO arrays rather than just the VARIABLE_INFO array.

… array anymore.

… its parameters.

…nts().

…bles().

There was never a need to initialise them there in the first place. In fact, an external variable is effectively an algebraic variable which is computed by an end user. So, it needs to be computed in computeRates() (if available) and in computeVariables().

Also fixed an issue with initialiseVariables() not always including the VOI.

…ble.

Even if the NLA equation only uses constant variables and constant values.

Constants are indexed using makeConstant().

…e header.

…ded to initialise a state.

Oversight on my part!

This effectively reverts commit b1b7536.

Indeed, some computed constants are initialised using an equation (e.g., x = 3 rather than x with an initial value of 3). So, there is no need to compute those computed constants many times (using computeComputedConstants()). Instead, it's much better to compute them in initialiseVariables().

Not to mention that we might have "computedConstants[1] = 1.0;" and then "computedConstants[0] = computedConstants[1];" so if we were to compute both of them in computeComputedConstants(), we would need to compute "computedConstants[1] = 1.0;" before computing "computedConstants[0] = computedConstants[1];", which would make things slightly more complicated to generate.

… its parameters.

…bles().

…ded to initialise a state.

…c arrays rather than the variables array with findRoot() & Co.

…c arrays rather than the variables array to compute external variables.

…ternal variables.

…llml#1247.

…HH52 model with various external variables.

…dUnknownWithExternalVariable.

This is so that we can test an algebraic model with an external variable (in https://github.com/agarny/libCellMLGeneratedCodeTests).

Indeed, we want to be able to tell the generator to track/untrack some model variables. So, to have those `model()` and `setModel()` methods make the generator model-specific when we want it to be usable for any model, hence now the `interfaceCode()` and `implementationCode()` methods taking a model as a parameter.

Someone might have a version of llvm-cov and llvm-profdata that they use and which is not located in /Library/Developer/CommandLineTools/usr/bin. This means that they will need to provide LLVM_BIN_DIR which is not ideal, not least since there are PREFERRED_LLVM_COV_NAMES and PREFERRED_LLVM_PROFDATA_NAMES to play with, if needed.

…m a Variable object.

Someone might have a version of llvm-cov and llvm-profdata that they use and which is not located in /Library/Developer/CommandLineTools/usr/bin. This means that they will need to provide LLVM_BIN_DIR which is not ideal, not least since there are PREFERRED_LLVM_COV_NAMES and PREFERRED_LLVM_PROFDATA_NAMES to play with, if needed.

…ble is not tracked per se.

This is for the VOI and states which are not tracked per se, but should be considered tracked.

…ing some code.