Changes between Version 11 and Version 12 of Development/Patches

Show
Ignore:
Timestamp:
02/24/10 03:45:06 (5 years ago)
Author:
benl (IP: 129.94.242.38)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Development/Patches

    v11 v12  
    1616}}} 
    1717 
    18  This will clean out the libraries and test directory, rebuild the libraries, then run all the regression tests. If all the tests pass, then go ahead and send/push your patches. 
     18 This will clean out the libraries and test directory, rebuild the libraries, then run all the regression tests in the normal (non-optimised) way. This is the ''minimal'' required testing before pushing patches into the head branch. If you've made a deep change to something like the type inferencer or core transforms then you should run all the tests in all possible ways: 
     19{{{ 
     20  make cleanLibrary 
     21  make cleanWar 
     22  make totalwar 
     23}}} 
     24 
     25 If you've added a lot of files to the version control system (`darcs add`) and might have forgot some, or you just want to be extra sure you're not going to break anything, then it's best to use a separate testing repo. First make a new version of the head repo (maybe called `ddc-head-test`). Record your patches in the original repo, push them into the testing repo, then in that repo do: 
     26{{{ 
     27  make cleantotal 
     28}}} 
     29 
     30 Using this method has the additional advantage that in the testing repo you can leave the `BUILDFLAVOUR` set to `distro`. This means that the compiler itself will be built with optimisations turned on, and the tests will go through a lot faster. 
    1931 
    2032 * If your patch adds a new feature then it should also include a test case for it. Submit the test case in the same patch as the code for the feature.