Re: [PATCH] gnu: Add libjxr.

[Kei Kebreau]

address@hidden (Ludovic Courtès) writes:

> Kei Kebreau <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> Leo Famulari <address@hidden> 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 <address@hidden>
>>>>> >> +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’.

I ended up using the '--binary' flag, but the libjxr patches still need
to be converted to DOS format to function properly. The current
procedure to get this patch running is:

$ git am 0001-gnu-Add-libjxr.patch
[whitespace complaints]
$ sed -i -e 's/\r*$/\r/' gnu/packages/patches/libjxr-fix-*
$ ./pre-inst-env guix build libjxr

The DOS formatting issue also keeps me from using 'substitute*' to patch
the Makefile to build both a shared and static version of the library.
The current package only builds a static version. Everything seems to
link properly for now, but I don't know if that will be required in the
future.

0001-gnu-Add-libjxr.patch
Description: Text document

signature.asc
Description: PGP signature