kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/12/2013 05:19 AM, Brian Sidebotham wrote:
> Hi Dick,
> 
> Sorry, I don't mean to waste your time by passing everything under your nose before
> committing, but I would rather get a quick ok and then commit the following.
> 
> BZR4454 breaks windows builds because bzr patch fails on re-applying a patch that has
> already been applied to the branch of an external project. There are no switches available
> to ignore previously applied patches and so it just fails.

I don't think the problem is specific to commit 4454.  And it is not unique to windows.
One way forward on linux was to first

    $rm -rf <cmake_source_root>/.downloads-by-cmake/boost_1_54_0/

This kept the download, but removed the un-tarred boost source.
Then run the build.

Or do a 'make clean' first.

But since 'bzr revert' succeeds even on a pristine branch, your solution seems to be OK.
If ever that were to change, (bzr revert succeeding on a pristine branch), it would no
longer work.

Below is a starting point for a commit log entry:


"

Although CMake keeps time stamps to remember how far it got in an ExternalProject_Add()
build, it throws the time stamps away when there are edits to the CMakeLists.txt portion
pertaining to the external project.  Only a 'make clean' would remove the untarred tree.
This patch removes the need to do a make clean when changing the ExternalProject_Add()
text pertinent to patching.





> 
> This obviously breaks Winbuilder. I propose that we simply revert the branch at the start
> of patch change. I think CMake is "intellegent" enough to know that only the patching has
> changed and so this is all that gets run. On adding a patch to the list it doesn't delete
> and start again so patching fails. I guess it's a reasonable advantage actually that we
> can then easily alter the patch set of these external projects and having the bzr repo
> means we can easily just revert and re-apply a patch set and re-compile. This is much
> faster than the brute force delete and start again approach!
> 
> So the attached patch reverts the repo before applying the patch set. This fixes windows
> builds, perhaps it's different on Linux? I haven't had time to test but it should be
> entirely safe.
> 
> If you're happy and I'll go ahead and commit.
> 
> Best Regards, Brian.
>