On Mon Feb 25 18:56:44 2008, doughera wrote: > > Yes. Exactly. I have been arguing that point for years. Every step > can involve triggers, or callbacks, which can invoke arbitrary code > and even change the results of preceeding steps. It is very much > history-dependent. I think the best disk cache of such information is > lib/Parrot/Config/Generated.pm, because only that file represents the > best guess of a successful configuration.
The problem with lib/Parrot/Config/Generated.pm is that it's not available pre-configuration, only post-. But since it is essentially a dump of the final state of the most important parts of the Parrot::Configure object, it's probably close to the final state of the Parrot::Configure::Parallel object as recorded in the Storable file. Which suggests we can get snapshots at the end of each of the non-final config steps and make use of that data during testing. > > At the > moment, it has the same problem as the previous design -- it's failing > to honor my command line arguments. Whether that will be easier to > fix in this design or not, I don't know. It should be. In the previous design, there was no way to get your command-line arguments through to the individual test files. 'prove' (and the code in Test::Harness underlying it) didn't have that capability. Now with App::Prove (to which I'm switching, to avoid a system call to 'prove') lets us do that. > > I can only observe that every layer of complexity is making it *harder* > to debug failing tests. Having a binary hidden cache file only adds > another layer of complexity. It's important to remember that > when Configure (or its tests) fails, it is usually on someone else's > machine where you don't have access and where getting reliable feedback > to fix the problem entails mailing back and forth with a (possibly > inexperienced and probably busy) user who might not be willing or able > to peel back layer after layer of complexity to help solve the problem. Agreed. But since Configure.pl itself is very stable these days, most users won't have to bother with the '--test' option. Just as with other non-'make-test' tests (e.g., make manifest_tests, make buildtools_tests), they'll be things that people will be advised to run if they're hacking in certain areas of the distribution, and that we'll have to run pre-release -- but not on an every day basis. kid51
