Re: [Doxygen-develop] CMake

[Bastiaan V. <Bas...@SA...>]

Hi,

I must admit that I haven´t studied this in great detail, but if most 
binary dependencies are available for windows from somewhere, so that 
cmake would work well for 90% of the dependencies, one possibility for 
the remaining 10% would be to distribute binaries on the doxygen site 
for the sole purpose that cmake can download them from there. What are 
the percentages actually?

It may be an obvious thing to say, but I thought I´d bring it up 
nonetheless.

Bastiaan.

On 18-6-2013 19:17, Robert Dailey wrote:
> Sorry for the delay in response.
>
> So basically the problem is between Windows and Linux. On Windows, I
> do not have a package manager. It's a huge pain in the ass to download
> each dependency, as well as its dependencies (transitively) and build
> each individually. This takes sometimes days, and is impossible to do
> depending on what libs you use. If anyon tried to build SVN on Windows
> 5 years ago, they would know what I'm talking about.
>
> However on Linux, things are much easier in this respect. It's OK to
> let the user install the dependencies because they just type in
> apt-get and they are done.
>
> find_package() is ideally the cross-platform way of handling
> dependencies in CMake, but the problem is just that: Fulfilling the
> dependencies, as I noted above, is rather painful on Windows. Not only
> that, but CMake doesn't come pre-packaged with find modules for each
> and every library known to man. For any libraries that CMake does not
> know how to search for, you must write the corresponding find package
> script. Granted it's a one time thing, but adds the occasional extra
> maintenance.
>
> If we go with find_package in Cmake, which is the most-likely approach
> we will have to take, then we will be required to have *compiled*
> versions of dependencies on the system. Whether that means the package
> manager on that distro already downloads the binaries *or* the
> additional step of building them must be taken, is outside of the
> control of CMake. It'll have to be something that is taken care of
> externally (I think this is the case already, based on the feedback so
> far).
>
> Can anyone think of an easier way to setup dependencies on Windows? QT
> has an installer which is fine, and CMake also already has a find
> module for it that ships with CMake. What about the others? For
> example, if we depended on OpenSSL, it's rather painful to build on
> Windows outside of Cygwin (even with Cygwin, you still have to setup
> the environment to point to the correct compiler & stuff, much easier
> to run the Visual Studio bundled command prompt scripts). In those
> cases, getting up and running on Windows can still be a pain :(
>
> On Wed, Jun 12, 2013 at 1:10 AM, Torbjörn Klatt
> <ope...@to...> wrote:
>> -----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-----
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Doxygen-develop mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop