Re: [Doxygen-develop] CMake

[Torbjörn K. <ope...@to...>]

-----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 <mg...@we...>
> 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-----