Kei Kebreau <k...@openmailbox.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Leo Famulari <l...@famulari.name> skribis: >> >>> On Sat, Oct 22, 2016 at 04:33:18AM -0400, Kei Kebreau wrote: >> >> [...] >> >>>> >> diff --git a/gnu/packages/patches/libjxr-use-cmake.patch >>>> >> b/gnu/packages/patches/libjxr-use-cmake.patch >>>> >> new file mode 100644 >>>> >> index 0000000..cb5919e >>>> >> --- /dev/null >>>> >> +++ b/gnu/packages/patches/libjxr-use-cmake.patch >>>> >> @@ -0,0 +1,143 @@ >>>> >> +Description: Prefer a cmake based build system >>>> >> +Author: Mathieu Malaterre <ma...@debian.org> >>>> >> +Forwarded: https://jxrlib.codeplex.com/discussions/440294 >>>> > >>>> > Why doesn't upstream's build system work? >>>> >>>> Upstream's build system simply doesn't have configuration or >>>> installation targets in the provided Makefile. Using the cmake patch >>>> makes the definition cleaner at the cost of relying on outside work >>>> [1]. If this is not acceptable, I can see about writing manual >>>> replacement phases to the best of my ability. >>>> >>>> [1]: https://jxrlib.codeplex.com/discussions/440294 >>> >>> Hm, not an ideal situation. >>> >>> If Debian is using this patch, we should link to it's source on Debian's >>> site instead of this message board. I don't know enough about CMake to >>> judge the patch but I'd be more comfortable if Debian was using it. >>> >>> What do others think? >> >> Regarding the choice between writing our own installation phase in >> Scheme and using this CMake thing instead, I think we should choose the >> most concise approach (in terms of lines of code). >> >> If the winner here is the CMake patch, then indeed, we should take the >> patch from Debian rather than from a message board (and include >> provenance information in the patch, as you wrote.) >> >> That said, I suspect an ‘install’ phase in Scheme would be more concise >> than this new CMakeLists.txt (134 lines). >> >> Kei: WDYT? >> > > I have been working on writing our own installation phase, and it looks > like it will be more concise.
Cool, thanks! > However, the patches need to be in DOS format to apply. The patch > doesn't seem to carry these line returns, which leads me to believe > that a standard git configuration won't accept them. Is there way > around this? But that’s unrelated to removing the CMakeLists.txt patch and adding your own install phase, right? :-) >From the description I’m not sure exactly what the problem is, but perhaps the ‘--binary’ option of ‘patch’ can help? You can specify it in ‘patch-flags’: https://www.gnu.org/software/guix/manual/html_node/origin-Reference.html Ludo’.