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 >
