Right now for X2MBC development, my test projects have been lwotc, CI, and CHL. They exercise radically different parts of X2MBC (asset cooking, HL cooking, massive content/localization setups, large script packages, IncludeSrc. macros) which sounds great in theory, but these differences mean we can't feasibly test parts of the incremental system.
An example would be trying to ensure the compiler for base-game packages isn't needlessly invoked even when switching between mods. CI uses extra_globals.uci, and any changes to macros causes all script packages to be deleted, so switching between CI and lwotc will always (correctly) call the base-game script compiler again (I'm not sure if this is a great example because it needs more investigation, but I've hopefully established the general idea that vastly different projects don't exercise the smaller details in incremental logic).
We should create a repository with a number of test projects and identify interesting build orders that can automatically be invoked to test them, preferably also with a way to match log output in order to describe that a certain build should skip a certain step or not.
Right now for X2MBC development, my test projects have been lwotc, CI, and CHL. They exercise radically different parts of X2MBC (asset cooking, HL cooking, massive content/localization setups, large script packages, IncludeSrc. macros) which sounds great in theory, but these differences mean we can't feasibly test parts of the incremental system.
An example would be trying to ensure the compiler for base-game packages isn't needlessly invoked even when switching between mods. CI uses
extra_globals.uci, and any changes to macros causes all script packages to be deleted, so switching between CI and lwotc will always (correctly) call the base-game script compiler again (I'm not sure if this is a great example because it needs more investigation, but I've hopefully established the general idea that vastly different projects don't exercise the smaller details in incremental logic).We should create a repository with a number of test projects and identify interesting build orders that can automatically be invoked to test them, preferably also with a way to match log output in order to describe that a certain build should skip a certain step or not.