On Jan 18, 2008 7:39 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > Note: Application of the patch attached entails a change in behavior. > It will no longer be possible to say: > > svn update > perl Configure.pl > svn update (assuming a new revision number is displayed) > make > > ... and be able to make 'successfully'. tools/build/revision_c.pl will > now die should you try to do so. > > I put 'successfully' in quotes because the current behavior is that if > you do an svn update and get updated files after configuration but > before build -- meaning your build no longer strictly corresponds to a > single state in the repository -- you can run 'make' to its conclusion > but when you call 'parrot --version' you will get warnings. But to > respond to those warnings you have to do what you should have done in > the first place, namely, go directly from configuration to build. > > Eliminating this toleration for bad programming practices simplified the > code considerably! > > Please review. I'll apply in 2-3 days if there is no objection. Thank > you very much. > can you still do: svn update perl Configure.pl make svn update (new revision) make ??
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.) ~jerry
