On Sat, Jun 02, 2018 at 11:58:21AM +0300, Juhani Numminen wrote: > On Fri, 1 Jun 2018 21:12:06 +0200 Sébastien Villemot <sebast...@debian.org> > wrote: > > Package: src:rkward > > Severity: serious
> For a build log of the failure, see the link "rbuild (41KB)" at [1]. > > It seems that the cmake invocation is causing trouble. Consider these forms: > > 1) CC='gcc -std=c99' cmake ... > 2) CC='gcc -std=c99' cmake -DCMAKE_C_COMPILER='gcc -std=c99' ... If you look around passing spaces in CC to cmake, you'll quickly see that this generally doesn't work well. Yes, there is a hack that can separate one argument from the path, but that is more of an implementation detail as far as I understand it. Thus I believe that this usage is expectably prone to breakage. Not supporting spaces in CC seems reasonable to me. > The first one is okay and CMake handles the extra -std=c99 argument properly, > but > the second one causes "-- The C compiler identification is unknown". > This behavior is expected as CMAKE_C_COMPILER should be a full path.[6] > > Debhelper[2] uses the second form when CC is set, as is done in rkward[3]. > The change was introduced in [4], to fix #897083[5]. > (Helmut Cc'd to notify of this unexpected breakage.) Yes, the attribution to this debhelper bug is correct. The proper way to pass -std=c99 would be CMAKE_C_FLAGS as far as I can tell. > On the other hand, maybe debian/rules of rkward needs to be changed. The > comment > at [3] states that setting CC is required for "some installations of R", but > is > it required in the Debian package specifically? > > In this case, 'gcc -std=c99' comes from "/usr/bin/R CMD config CC". > I am also wondering why R should impose -std=c99. There exist many other > possible > values for -std.[7] Stuffing flags - and in particular -std=c99 - into CC looks wrong to me. Maybe reassigning to R is the way to go. Also note that using plain "gcc" here breaks cross compilation. R should certainly return a triplet-prefixed CC like python does. Most debhelper changes break some package. This one is no different. The number of affected packages seems low to me and the feature being broken was known to be fragile. I think it is reasonable to keep the new debhelper behaviour. Helmut
