Re: Bug#832748: ITP: greatcmakecookoff -- Usefull and less than usefull cmake recipes
Hi Sune,
I must say that I agree with you; the code is not of very high quality,
some places are especially ugly in a Debian build (automatic or forced
download of external packages).
However, it is not just "works-for-me", since it is used in a different
place from where it was developed, so the code found its friends
(unfortunately).
You are right, the current published upstream version does not use CMAKE
at all. However, they have a private development branch (which will be
made public in the next time) which since 2 years rellies on cmake and
GreatCMakeCookOff. I have access to it, but since it is private, I can't
open this yet. For me (as a cmake-strawman) it looks non-trivial to
remove this dependency, although I really would like to.
If I can't remove it, I in principle have two choices here: either I
include it in each package; this would however violate the policy §4.13.
Or I package it separately, then I am close to the "must not be so buggy
that we refuse to support them" requirement in §2.2.1.
Best would really be to get rid of it completely; however my contact to
upstream is still too short to ask them for a major change in their
build system, just before the want to release it.
If you (or someone else) could volunteer to help me in removing this
dependency, I would be glad, and would withdraw the ITP.
Or do you have better ideas?
Best regards
Ole
Am 28.07.2016 um 20:11 schrieb Sune Vuorela:
> On Thursday 28 July 2016 15:33:55 Ole Streicher wrote:
>
>> URL : https://github.com/UCL/GreatCMakeCookOff/wiki
>> Description : Bunch of CMake pain in the baker
>> This is a repository of useful and less than useful CMake recipes.
>
> After reading it thru, I would really like to question the inclusion into the
> archive.
>
> It seems like undertested, fragile works-for-me-and-probably-no-one-else cmake
> code.
>
> There is a couple of find modules that might be interesting, but I would
> really suggest to get those upstreamed into either cmake or extra-cmake-
> modules and the rest of the hacks should preferably not be used.
>
> I took a look at sopt and purify upstreams, and couldn't find that they used
> cmake at all?
>
> /Sune
>
Reply to: