assimp is not included in the source code tarballs

PaddyMac

I'm trying to update the Gentoo ebuild to the new 2.0.1 release. So I'm trying to compile Doomsday from source. But the first problem I've run into is that when I download a tarball (or the master.zip), the sources for assimp are not included for some reason. Is this intentional, or is this some oversight? Cmake fails as a result. I downloaded an assimp tarball and extracted it into the proper directory in the Doomsday source tree, but it appears that the assimp version in Doomsday's source tree is fixed at a specific version. Will using a different version cause problems? Is assimp customized or patched in some way, or is it simply an old version?

skyjake

Doomsday uses a slightly customized version of Assimp. It is a Git submodule on the GitHub repository, so you'll need to either use the source tarballs from http://dengine.net/source or use "git clone --recursive" to check out the full sources.

PaddyMac

Thanks. Getting the right tarball helped. The only issue I'm not yet sure how to best handle is that, when I compile and install the software, it wants to install the assimp headers into /usr/include/assimp which is the same location as the unmodified libassimp's headers. They can't both exist in the same location, so unless someone has a better idea, the solution I'm using now is to set -DASSIMP_INCLUDE_INSTALL_DIR:PATH=include/doomsday so that Doomsday's version of the headers are in a subdirectory. I examined your Debian packages to see how you handled it, and they're installed to /usr/include/assimp, so I'm a little surprised no one has reported file collisions with assimp with the Debian packages (unless Debian's assimp is installed to a non-standard location, Debian allows files to be overwritten without warning, or by some random chance no one has tried to install assimp and Doomsday on the same Debian machine).

skyjake

Well, the good news is that installing the Assimp headers is in no way required by Doomsday, so they can be safely omitted from any (binary) installations. (The headers are naturally needed for compiling.)

The not so good news is that for distribution purposes Doomsday has been configured to use CPack and the CPack installation components mechanism. There is a component reserved for headers and libraries ("SDK"), which should include the Assimp headers as well.

PaddyMac

This is not an opinion specifically directed at Doomsday but a general opinion. If you're going to use a modified version of a library, that's fine. But if you're going to do so, you really ought to do one of two things: 1) submit the changes upstream so they can be integrated into the project, or 2) if you're unwilling to submit the changes, or upstream won't accept the changes, you should rename the modified library so that it can coexist with an unmodified version.

If the modified assimp won't be integrated upstream, I personally think it would avoid a lot of potential downstream problems if it were renamed. It could be as simple a change as d-assimp for "Doomsday Asset Importer", but that would be enough.

skyjake

Thanks for the suggestion, I will consider it.

There are basically two kinds of changes that I've done to Assimp:

1) Modify the Assimp build config so that it is integrated into the Doomsday CMake build. These changes are rather Doomsday-specific so I would lean against submitting them upstream. Instead, it would make more sense to add the option of using an existing Assimp installed on the system instead of the one in doomsday/external/assimp.

2) I've also slightly tweaked the Assimp MD2 and MD5 importers. These changes could be submitted upstream, but the community seems to be favoring FBX anyway so these changes might even be discarded as unnecessary.