Re: Bug#832748: ITP: greatcmakecookoff -- Usefull and less than usefull cmake recipes
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
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?
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
> It seems like undertested, fragile works-for-me-and-probably-no-one-else cmake
> 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?