Re: [Doxygen-develop] CMake

[Michael S. <ms...@re...>]

On 11/06/13 20:05, Markus Geimer wrote:
>> 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).

that's all very true.  there is a sort of "compromise" between bundling
stuff and not bundling stuff that is used by LibreOffice:  we have
dozens of external libraries that are bundled, and we can build all of
these during the LibreOffice build, but they are not actually included
in the git repo or in source tarballs.

it works like this:

1. configure has for most externals a --with[out]-system-foo switch to
determine if it should be bundled (defaults to bundled on Windows)

2. if configure says it's bundled, then a source tarball is
automatically downloaded from somewhere.libreoffice.org

3. the tarball is unpacked, some patches are applied (most things don't
build out of the box on all platforms), the external thing is built and
its libraries copied to well known library dir

of course Doxygen has a lot fewer dependencies and so a much smaller
problem so i wouldn't recommend to copy the approach exactly but perhaps
it can provide some inspiration.

most likely it's not necessary to build bundled libraries on Linux,
because package managers allow to easily install stuff there, it's more
of a problem for Mac and Windows.

>>>>>> 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.

yes, if you want to distribute binaries of Doxygen that are supposed to
run on any old Linux system you need to think about this; it's not just
libstdc++ but also glibc, or well any system library really.

for LibreOffice we build the upstream release Linux binaries on a RHEL5
system (very old versions of everything) for that reason; for
OpenOffice.org a similar approach was used with an NFS-mounted baseline
of libraries and the GCC --sysroot (which prevents it from looking in
standard system dirs).

but given that there's a Doxygen package for every distro anyway and
it's a developer focused tool (so users can be expected to build it from
source if needed) i'm not sure why you'd bother to do this :)