Feature/fix install cmake

Why do you think that a lib of bash functions or dune.module is architecture dependent?

Edit: I get it. You want to be backwards compatible with autotools on broken SUSE systems that use lib as libdir. Still I would prefer to adapt Makefile.am for this.

I guess the correct fix would be to use the doxygen documentation from the tarballs, e.g. ${CMAKE_CURRENT_SRC_DIR}/html if no doxygen is found.

Tarballs will no longer (Dune 3.0+) have Doxygen with them. We will provide source tarballs and no longer prepared/precompiled/enhanced tar files.

The proper fix would be to have Doxygen as a build requirement when building RPM packages, but I postponed this hassle.

But this is the 2.4 release. Does this even trigger and error that can be fixed by some quotation marks.

No html subdirectory is created?!

I haven't check. The problem occurs earlier, when the target doxygen_dune-foo is called but was never created.

Probably because I never though about the location of dune.module and the *.lib files. Why are they in lib anyway?

Maybe ${CMAKE_INSTALL_LIBDIR}/../lib would be better then CMAKE_INSTALL_BINDIR. Would that be ok for you?

Coming to think of it again, the real reason to use a path relative to CMAKE_INSTALL_BINDIR is:

The problem was that user/sysadmin might overwrite CMAKE_INSTALL_LIBDIR and/or CMAKE_INSTALL_BINDIR. There is no easy for dunecontrol to guess which value CMAKE_INSTALL_LIBDIR was set to. But as dunecontrol gets installed into CMAKE_INSTALL_BINDIR it can assume that ${CMAKE_INSTALL_BINDIR}/../lib is the correct place of the lib.

Note that for autotools we still have the same problem, but I was not willing to invest time there.

Ok, that sounds like an argument. I'll give it a try whether I can modify the package build scripts accordingly. I'll report back.

The same holds for dune.module.

Even in the current situation I am sure that I missed some scenarios. I guess the only way to be safe is to export the DUNE_INSTALL_NONOBJECTLIBDIR variable and possibly others with the package configuration file. Then dunecontrol can query the correct path from it using cmake. Might make dunecontrol a little less complicated...

Added 2 commits:

• 6fcb9f2e - [CMake] Update error message to reflect all checked paths.
• c2f3853c - [CMake] Don't add doxygen_${ProjectName} target without Doxygen

Ok, dropped two of the commits. Objections concerning the remaining two? I still consider it a bug if the doxygen_* target is created despite Doxygen is not found.

No.

Unmarked this merge request as a Work In Progress

mentioned in commit fa6bc4af

Status changed to merged