Re: [PATCH] gnu: Add libjxr.

[Kei Kebreau <kei@openmailbox.org>]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Leo Famulari <leo@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 <malat@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. 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?

> Thanks!
>
> Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]