-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all
On 12.06.2013 04:47, Anthony Foiani wrote: > Robert, Markus, all -- > > On Tue, Jun 11, 2013 at 12:05 PM, Markus Geimer <[email protected]> > wrote: >> 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? Only ever do this for libraries which do not provide pre-built Windows binaries or where most linux distributions do not provide packages (which is very very rare). And even then you really need to know what you are doing and should prefer to let the use resolve these dependencies on his own. He/she knows the system well better than you ever do via CMake. CMake's purpose is exactly to overcome the need to create such monstrosities of bundles and maintenance nightmares. >> >> I strongly recommend to *not* create such a monster tarball >> because of various reasons: > > I very strongly concur. > > Robert's proposal (create private copies of everything) was the > route taken by Chromium. Getting it accepted into Fedora has been > delayed for years because the original packagers did not use the > libraries already available on the platform. > > (Not to mention the fact that, with the "monster tarball" > approach, you also need to keep up with security patches for all of > those programs you copied...) > > More info on this particular case here: > http://ostatic.com/blog/making-projects-easier-to-package-why-chromium-isnt-in-fedora > > >> 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. > > +1. > > I can't believe that CMake doesn't have this capability already, > even if it's in the guise of "is this symbol available from any > known library on the system?" CMake does have such possibilities. It's called FIND_PACKAGE(mypackage REQUIRED) This will abort the whole configuration step if 'mypackage' is not available on the system (read: not found in system's paths). E.g. to require the Boost system and regex libraries and headers of version 1.50 and later one writes FIND_PACKAGE(Boost 1.50 REQUIRED COMPONENTS system regex) For a list of somehow inbuilt supported packages to search for see [1] and all items starting with 'Find'. In case the desired package is not in this list, one usually finds such via Google (or GitHub) easily. If you ever encounter a library where no FindX module is available, you should try detecting existence on the system via the low-level CMake commands FIND_LIBRARY and FIND_PROGRAM which are used by the FindX modules. [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#section_StandardCMakeModules > > Either way, I do wish Robert luck; CMake has the potential to > improve cross-platform projects quite a bit, but I agree with > Markus that bringing in tarballs of dependencies is not the right > way. I sign this. > > Best regards, Anthony Foiani Cheers, Torbjörn Klatt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRuBDpAAoJENyw9v81DsTG5PwIAKSjp8gClLd5gOGF8OIeo0QO lzc8G7Kvn6wwSpklJqiVKFE3FA3y3y1bnnOOj4nSCycLgJFUFUhaWekCYHYM0yWJ CCjj2EExFGs6J1gKkopInEmEhj5REhKJwTZzZjs88kGqVCbiZgE6LWkDTJd4PjE7 dSl+sLdJZRWyadzgyDpG6kWBs0eE0EKtT+Nql94nXrWTP1nDoSp/fQZevpyBP5++ fq2D9UufgpBkossXfEQN2MxwzEZduX4MmvUBd5PBKwleI+PXQAM86l+t09A5Hpiu I28+YUQQYStFD9ztgu91ps/Vs7dJxzlAvqs56PcdgNCnZTdjwt9JML8IjNzUiW8= =UNdQ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
