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