<p>Am 03.07.2012 12:23 schrieb "JC Chu" <<a href="mailto:jcchu@acm.org">jcchu@acm.org</a>>:<br>
><br>
> On Tue, Jul 3, 2012 at 3:55 PM, Sven Barth <<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>> wrote:<br>
> > I don't know whether you know this, but:<br>
> > * testing the compiler compilation (as a first step) is best done using<br>
> > "make cycle" in the compiler subdirectory (optionally "make fullcycle" if<br>
> > you changed something were a subset of the supported platforms is affected)<br>
><br>
> I did “make compiler” in $(source)\compiler and copied the resulting<br>
> executable to my scratch directory.  No wonder I didn’t find out the<br>
> error.  (ಠ_ಠ)</p>
<p>Now you know a better way :)</p>
<p>> > * if the compiler can be compiled you should do a "make clean all<br>
> > TEST_FPC=path/to/your/newly/compiled/ppcXXX" in the "tests" directory and<br>
> > compare with a testrun of the same version without the modifications (it's<br>
> > sufficient to copy the "log" or "faillist" file from the<br>
> > "tests/output/yourcpu-youros" directory for comparison)<br>
><br>
> Could you elaborate on that?  Do I need to run the test suite with the<br>
> old compiler first?</p>
<p>* first do a "make cycle" on a unmodified checkout, then run the testsuite. <br>
* save the "log" and/or "faillog" file<br>
* do your modifications (might involve some "make cycle" executions until you're satisfied with the results)<br>
* run the testsuite again and compare the new "log" or "faillist" file against the backuped counterpart<br>
* if there are no explainable changes in succeeding/failing tests: publish your patch<br>
* otherwise correct your changes so that you don't introduce regressions and repeat at point 4</p>
<p>Regards,<br>
Sven</p>