Reini, I would argue that we take a different approach with 'make reconfig'. We need to get rid of it entirely. In Parrot years, it's ancient code:
$ svn blame config/gen/makefiles/root.in | grep -n -A 3 reconfig ... -- 708: 4916 boemmels @echo " reconfig: 'clean' and redo configuration." ... -- 1769: 7554 bernhard reconfig : clean 1770- 22967 bernhard $(PERL) Configure.pl And it doesn't DWIM. Nowadays, if you want to redo configuration, you need to call 'make realclean', as 'make clean' does not delete the files created by Configure.pl. (If you want to re-run one particular configuration step, use tools/dev/reconfigure.pl.) I guess that the existence of 'make reconfig' completely escaped me. If I had known about it, I would have recommended excising it, as it's inconsistent with the way Configure.pl has worked for at least two years. Now, there may very well be other reasons to retain the command-line options. Parrot::Configure::Options processes those options, and the most important of them are available for the lifetime of the Parrot::Configure object. Given that, the question arises as to whether they should be retained in the Makefile and/or in Parrot::Config. I'm now developing file-based configuration in a branch, and in that branch I've chosen to store the parsed version of that file in Parrot::Config. So, my recommendation is to hold off on deciding how to store command-line options for the next week. After I present this patch for file-based configuration, we'll be in a better position to decide how/where to store the command-line options data. Thank you very much. kid51
