dcoughlin added a comment. In http://reviews.llvm.org/D14345#281475, @xazax.hun wrote:
> Hi! > > I think it is great to support this model in these scripts. Do you plan to > check the list of the project urls in to the repository as well? The project URLs are implicitly included in the download script (which is checked into the repository). So, for example, here is a sample script to download the OmniGroup project from github: curl -L -O https://github.com/omnigroup/OmniGroup/archive/c9074bc24c46516687acf44824ad8b00c2146ad6.zip unzip c9074bc24c46516687acf44824ad8b00c2146ad6.zip mv OmniGroup-c9074bc24c46516687acf44824ad8b00c2146ad6 CachedSource > I have one minor high level note about the handling of patches. I think it in > case a project would need more modifications, it is cleaner to have a > separate patch file for each kind of them. Maybe it would be worth to support > patching the project with multiple patches? E.g. applying all patches with a > name prefix. I originally did it this way but I found that became cumbersome. In order to fix an issue I had to copy the original pristine source, apply all previous patches to that copy, then copy the patched tree, then fix the issue in the second copy and the diff first copy with the second to generate the incremental patch. With the single-patch approach the workflow is: copy the pristine source, apply the patch to the copy, fix the issue in the copy, and diff the pristine and the (now fixed) copy. Since these patches are checked into the repo, they can always be differed with older versions of the patch to see what has changed. http://reviews.llvm.org/D14345 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
