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 :) ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Doxygen-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/doxygen-develop
