On Jan 18, 2008, at 10:49 PM, Jerry Gay via RT wrote:
can you still do: svn update perl Configure.pl make svn update (new revision) make ??
No. 'make' invokes tools/build/revision_c.pl, which has this restriction in it:
exit 1 unless ( $current == $config );
this is a common scenario for developers. in the case where updating the working copy does not change any files that would affect the configuration process, the developer should not be forced to reconfigure. if this behavior is allowed, this patch should fit the bill. if not, then i'll have a problem with it. i certainly don't want to be forced to run configure and rebuild parrot from scratch every time i update my working copy (for example, if a pod comment was modified in a high-level language.)
Then we'll have to have a discussion of what we all want from revision-seeking code.
In developing this patch, I was primarily responding to the issue raised in this ticket: Paul Cochrane's and Andy Dougherty's observation that we were repeatedly asking what version control system was being used (which internally translated into repeated runnings of $Parrot::Revision::__get_revision_number() to get $Parrot::Revision::current). I was also responding to the bizarre (IMHO) structure of lib/Parrot/Revision.pm, where we repeatedly run the VCS-discovery code, assign it to $current, assign *that* to $config, and then -- at the very last moment -- say "Oh, by the way, if you've already configured, behave in a completely different manner. Assign a different value to $config." I had to write four separate test files to accommodate every twist and turn in this code.
What happens under different scenarios if you comment out the 'exit 1' code above in revision_c.pl?
