How about using a submodule for this instead? That way:

• we can more easily update it in the future
• more secure updates, this update is so big that it is difficult to review that no malicious code has been added

@wwmayer what do you think about migrating to a submodule, as @hyarion suggests?

we can more easily update it in the future

Sure.

more secure updates, this update is so big that it is difficult to review that no malicious code has been added

It's not really big. Most of the PR is about to put the automake stuff back that we will never use. The only change actually is to re-enable the copy constructor of the iterator class.

The copy constructor once has been disabled with 3883ef3 because it caused some compiler warnings in the mesh module. So, when we make this a sub-module is there a way to apply a patch to disable the copy constructor again?

So, when we make this a sub-module is there a way to apply a patch to disable the copy constructor again?

As far as I know, you can't apply local patches directly to submodules. Instead, the process would look like this:

• Fork the libkdtree repository to create a FreeCAD/libkdtree repository.
• Apply your local patch(es) in the FreeCAD/libkdtree fork.
• Use the FreeCAD/libkdtree fork as the submodule in your FreeCAD repository.

When you want to pull in changes from the original libkdtree repository, the process is as follows:

• In the FreeCAD/libkdtree fork, pull changes from the upstream repository and either merge them into or rebase your local patches onto the updated code.
• Push the updated fork, including your patches, to the FreeCAD/libkdtree repository.
• In the FreeCAD repository, update the submodule to point to the latest commit in your FreeCAD/libkdtree fork.