[External] Update pybind11 to 2.11

[matekelemen]

Changes

Update pybind11 to its latest release (2.11).

Instead of copying only the headers, I included all files in the repository because

1. it's more clear what version of the library we're using. This makes it a lot easier for companies using Kratos to validate our dependencies.
2. pybind11 can be directly integrated via CMake, instead of relying on pybind11Tools

As a result, I also got rid of cmake_modules/pybind11Tools.cmake and made the necessary changes in all applications' CMakeLists.txts.

Notes

Updating pybind11 has the happy sideeffect that symbols now get properly written to binaries if requested (in FullDebug, Debug and RelWithDebInfo modes), so tracebacks and profiling become actually useful.

[loumalouomega]

Clearly this is something to be discussed by @KratosMultiphysics/technical-committee

[loumalouomega]

RuntimeError: return_value_policy = move, but type Kratos::PointerHashMapSet<Kratos::ModelPart, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Kratos::ModelPart::GetModelPartName, std::shared_ptr<Kratos::ModelPart> > is neither movable nor copyable!

Looks like it would require some additional refactoring.

[matekelemen]

Looks like it would require some additional refactoring.

definitely. It will take some time to iron out, and I'll need to use the CI as my machine to do so ...

[RiccardoRossi]

I am not too positive about including all the headers. This makes bigger our repo...and that is already exploding ...

per regards the bumping up, can you list here the advantages (aside of the symbols you mention)?

[RiccardoRossi]

blocking as this is potentially disruptive (and huge)

[matekelemen]

I am not too positive about including all the headers. This makes bigger our repo...and that is already exploding ...

It does. Ideally we'd be using pybind that's installed on the user's system and not explicitly include it in our repository. Another solution would be to have pybind as a submodule (though that's an all new can of worms). I'm not sure who or why decided to explicitly include pybind in our repo, but since we have it in here, we must be transparent with what version we're using.

P.S.: the increase in size is 2.5Mb. There are single source files in our repository that are an order of magnitude larger than that, so I doubt this should be an issue.

per regards the bumping up, can you list here the advantages (aside of the symbols you mention)?

The last commit touching our pybind dates Aug 22 2022 but doesn't say what version it copied, so I'll assume it was the latest release at that time (version 2.10 dating Jul 16 2022). You can take a look at the changelogs since that release.

I cannot overstate the importance of having debug symbols in our builds though. Benchmarking without them is nearly impossible, and so is fast debugging in RelWithDebInfo.

If you don't want pybind updated, we should at least give users the option to provide their own version or fall back to the copy in our repo.

[RiccardoRossi]

I am not too positive about including all the headers. This makes bigger our repo...and that is already exploding ...

It does. Ideally we'd be using pybind that's installed on the user's system and not explicitly include it in our repository. Another solution would be to have pybind as a submodule (though that's an all new can of worms). I'm not sure who or why decided to explicitly include pybind in our repo, but since we have it in here, we must be transparent with what version we're using.

P.S.: the increase in size is 2.5Mb. There are single source files in our repository that are an order of magnitude larger than that, so I doubt this should be an issue.

per regards the bumping up, can you list here the advantages (aside of the symbols you mention)?

The last commit touching our pybind dates Aug 22 2022 but doesn't say what version it copied, so I'll assume it was the latest release at that time (version 2.10 dating Jul 16 2022). You can take a look at the changelogs since that release.

I cannot overstate the importance of having debug symbols in our builds though. Benchmarking without them is nearly impossible, and so is fast debugging in RelWithDebInfo.

If you don't want pybind updated, we should at least give users the option to provide their own version or fall back to the copy in our repo.

To clarify,
it is ok to me to include the versions. What i am not positive is about adding tests etc.

I agree that debugging symbols are ok, although i am not clear on the why with the current version is not possible.

we took the decision some time ago not to use submodules, and i believe this is somthing we should maintain

[philbucher]

it is ok to me to include the versions. What i am not positive is about adding tests etc.

I agree that debugging symbols are ok, although i am not clear on the why with the current version is not possible.

we took the decision some time ago not to use submodules, and i believe this is somthing we should maintain

Makes sense to me, I agree.

[RiccardoRossi]

my proposal would be to remove anything that is not strictly needed (rst files, html, tests etc) and eventually add a txt file acknowledging the version and the relevant info).

That would solve all technical issues and still keep low the number of files. What is that you dislike about this?