CMake automate download & build of Assimp code

[jlblancoc]

TO-DO (in a separate branch until stable):

• Remove assimp sources from MRPT / otherlibs. It's a huge project and it's a waste of space & time to maintain it here.
• Create CMake scripts to automate the download and compilation of ASSIMP from GitHub if the lib is not found in the system (mainly for Windows users). A fixed, stable release can be hard-wired in the code to be checked-out. Don't checkout git master or alike, since that would lead to non-reproducible builds.
• Create patch(es) over upstream sources to ease integration with MRPT. Current changes should be extracted from diffs in otherlibs/assimp subdirectory from these commits:
  • 441a11a#diff-5cbde633bb285c2feccca2ad3c62b1fc
  • e0f741c#diff-2a6e1d877e6c1598c2cc128a978c59a0
  • 3ff27a9#diff-3e9c51ce41f8752d72193fbd8b96c007
  • 494bba7
  • ba4be99
  • 87c4e6f#diff-3e9c51ce41f8752d72193fbd8b96c007

[jlblancoc]

Postponed to milestone 2.0.0, where we can require a newer version of CMake and will have stopped supporting Ubuntu Trusty.

[jlblancoc]

Removing from Milestone 2.0.0, since "Trusty" is already removed, at least from the PPA auto builds list.

[bergercookie]

@jlblancoc,

Create CMake scripts to automate the download and compilation of ASSIMP from latest GitHub release if the lib is not found in the system (mainly for Windows users).

Instead of just pulling and working on the latest Assimp release on github, I think it should be more robust to depend on a particular commit/release of the Assimp repo and periodically update that commit ID. This would ensure that nothing breaks in the MRPT compilation process if new non-backwards-compatible code is introduced to Assimp.

This can be implemented with Git submodules which are designed for maintaining and tracking 3rd party project dependencies.

[jlblancoc]

Good point! 👍
Just updated the 2nd task description to reflect that idea.

I liked GitHub submodules, but after working some time with them in another project, I'm now more inclined to prefer leaving that work to CMake, since we avoid having "anything special" in the "git domain"... thoughts?

[bergercookie]

I'm now more inclined to prefer leaving that work to CMake, since we avoid having "anything special" in the "git domain"... thoughts?

The "anything special" point is indeed true; unfortunately they do require special attention and can easily break stuff especially in cases that one develops both the outer repo and the submodule itself.

However, if one follows a basic set of rules, they are invaluable at splitting the work in separate repos. I have actually set up my entire catkin repo for the master thesis on git submodules.

Anyway, the CMake solution is pretty neat as well, and also more suitable in this case since MRPT do not hold any other tool as a submodule

[jolting]

I don't think that is the intent of submodules. Submodules really shouldn't be used to pull in other projects. A submodule should be a way of breaking up a single git repository into smaller pieces(modules), to avoid the issues associated with a large centralized software repository.

"What happens is that you do a single commit in each submodule that is
atomic to that private copy of that submodule (and nobody will ever see
it on its own, since you'd not push it out), and then in the supermodule
you make another commit that updates the supermodule to all the changes
in each submodule." - Linus Torvald

[spsancti]

Sorry, accidentally referenced this issue.
Sincerely, Borys.