Re: [Doxygen-develop] CMake

[Markus G. <mg...@we...>]

Robert,

> The only other thing I can suggest to remedy the dependencies problem
> is to bundle all dependency source code with Doxygen and build it
> along with everything else, much like you already do for libmd5. This
> also would include any dependencies of dependencies, transitively.
> This doesn't seem like it would be too big of a deal except for QT,
> which is pretty huge. Thoughts?

I strongly recommend to *not* create such a monster tarball because of
various reasons:

 - Most importantly, it will become a maintenance nightmare. Someone
   needs to keep track of new versions of all the dependency packages,
   and based on the changelog decide whether an update is required for
   doxygen (e.g., when a security issue has been fixed) or not.

 - Additional burden is put onto the distro package maintainers, as
   they will most likely patch the sources to use the system-provided
   libraries instead of the included ones (this is, e.g., already the
   case for libpng on Debian and maybe other distros).

 - It will unnecessarily increase build times for 99% of the users
   which have the common libraries already installed (not such a big
   deal if parallel builds are working, but Qt will be a killer).

>>>> I know that most linux distros have very different package managers.
>>>> Syntax is different, and some download binaries while others download
>>>> source. The source case will be difficult, as this custom script will
>>>> not only need to invoke the platform's package manager to download the
>>>> source but also build each package the moment it is downloaded in some
>>>> uniform way. Does this seem feasible?

Builds are normally done as ordinary user, while installation of
packages is done as root. So, trying to install packages using a
package manager at build time of doxygen sounds crazy to me.

>>>>> Another area to consider is the standard C/C++ libraries.  I have
>>>>> read the info behind the libraries, and found that this is where you
>>>>> could run into problems, as every std library is configured differently
>>>>> to make system calls to the Linux kernel.

Yep, libstdc++ would really be an issue. Typically, you can build
a binary against a version of libstdc++ and then run it using a
newer one, but not vice versa. Therefore, the best thing to do is
to always use the system-installed C++ library.

>>>>> It is much better to compile dependencies during the actual building
>>>>> process (like the QTools package in doxygen's source code).

Hmm... I disagree. Often, the dependencies are used by multiple
packages, i.e., you don't want to compile/install them multiple times.
And as soon as they are shared libraries, you might end up in a big
mess...

My recommendation would be to stick to proven best practices: Let the
configure step try to determine whether an appropriate version of a
dependency library is installed on the system, use it if available,
and complain (or disable optional functionality) otherwise. Of course,
there should also be a way for the user to specify an alternate
installation path to override the auto-detection and a list of all
dependencies including URLs in the INSTALL file (which I think is
already the case).

Best,
Markus