On 12/5/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > Not just the steps themselves need work, there is still some fairly > substantial work left to be done on the configure framework as part of > my refactoring project. This has been going rather slowly because it's > usually bad to major radical changes to a build system as things always > break, my available tuits have been rather low lately, and this isn't > 'test driven development' so I'm having to be doubly cautious about > breakage on platforms I don't have access too. My Parrot tuits > situation should be improved for the last week of December (a > 'vacation') and I'm hoping to complete most if not all of the > refactoring work then. >
<snip what's been done> > What still needs to be done: > > - The framework itself needs tests!!! > > - Each step needs to have it's own namespace. This is when the switch > to Module::Pluggable will happen. > > - Parrot::Configure::Step needs to be cleaned up. > > - Most of the steps need both style and logical clean ups. > > - It should be possible to specify the paths to all utilities via > environment variables. Similar to how the new probes for lex and yacc > work. > > - Parrot::Configure::RunSteps renamed to Parrot::Configure and the list > of steps to be run moved into Configure.pl > > - Steps need an option passing mechanism to specifying things like, we > require versions x, y or z of flex (or fail). This means reworking > the way CLI options are passed into tests. > > - A clean bailout mechanisms. Currently there is no 'nice' way for a > step to signal a failure, configuration always proceeds. > > - CLI options need some minor tweaks > > - Many steps should be broken up > > - The debugging traces could be neater > > - A usable log file would be handy > > - Makefile dependencies still aren't being setup rigorously > > - Last but not least, Leo's point about reviewing what the configuration > steps are actually doing. > wow... that's a lot of work. of course, the configure system is quite complex. might i suggest you break this down into bite sized chunks and create tickets for them? it seems some of these are pretty straightforward tasks that might be attacked by anyone with perl skils and tuits. in particular, i have a feeling there are quite a few lurkers out there--this may be a way to get some of them involved. also, it seems the setup of makefile dependencies is not directly related to the configure refactoring. there is currently one step: generate all makefiles. splitting this out into *at least* two steps (core makefiles, languages makefiles) is important for HLL designers, who must suffer through a parrot rebuild when their language makefiles change. but the makefile dependency changes, i feel, will happen parallel to the configure effort, as i think my project to shuffle directories around will affect this. ~jerry
