guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#27915] libnl additions


From: Marius Bakke
Subject: [bug#27915] libnl additions
Date: Thu, 24 Aug 2017 20:11:03 +0200
User-agent: Notmuch/0.25 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu)

Dave Love <address@hidden> writes:

> Marius Bakke <address@hidden> writes:
>
>> Sorry for the delay, these fell through the cracks a bit.
>
> No worries; thanks.  I don't mean to argue below, just explain.
> Apologies if this re-opens the issue -- I can't remember what debbugs does.
>
>>> * gnu/packages/linux.scm (libnl)[native-inputs, outputs]: Add doc source.
>>> [arguments]: New field.
>>
>> I ended up rewriting the install-doc phase so that it extracts directly
>> to the "doc" output, and adjusted the commit message slightly.  
>
> I wondered about that, but just did it as in rpm.  For info, are there
> policy or technical reasons for it?

I did it mainly to avoid the double copy.  Don't think there is any
policy or clear-cut technical reason (but avoiding I/O is good).

>>> [outputs]: Add python2, python3.
>>> [install-python]: New phase.
>>>      (native-inputs
>>> -     `(("flex" ,flex) ("bison" ,bison)
>>> +     `(("flex" ,flex)
>>> +       ("bison" ,bison)
>>> +       ("python-2" ,python-2)
>>> +       ("python-3" ,python-3)
>>
>> The Pythons here need to be regular inputs since they are referenced.
>
> I think the documentation could do with clarification in this area; I'll
> make a bug report about what's unclear to me.  (For what it's worth, I
> thought regular inputs would propagate to "out", and it wouldn't be
> important to depend on Python for the Python outputs.)

I was not sure where the references came from, just checked with `guix
gc -R /gnu/store/...libnl-python2`.  Looking closer, capi.so sems to be
linked against the various Pythons.

Documentation updates greatly appreciated!

>>> +           (add-after 'install 'install-python
>>> +             (lambda* (#:key outputs #:allow-other-keys)
>>> +               (define (python-inst python)
>>> +                 (let ((ldflags (format #f "LDFLAGS=-Wl,-rpath=~a/lib"
>>> +                                        (assoc-ref %outputs "out")))
>>> +                       (pyout (assoc-ref %outputs python)))
>>> +                   (and
>>> +                    ;; The rpm spec quoth "build twice, otherwise capi.py 
>>> is
>>> +                    ;; not copied to the build directory"
>>
>> I went ahead and removed this comment since we are not an RPM derived
>> distro, and always run "setup.py build" before "install" anyway.
>
> [I just meant to note an apparent deficiency documented elsewhere that
> might be relevant before the install step, e.g. in tests; I do the same
> for rpm if I'm looking at an existing dpkg.]  It's probably worth
> specifying using build before install in the manual if that's required.

Right.  Maybe removing the comment entirely was a bit rash.  I just
found it confusing, since we don't explicitly build it twice, but
eventually noticed that capi.py was "built" in the install step.

Anyway I'm sure the comment will reappear soon enough if this deficiency
indeed becomes apparent.  Thanks for following up. :-)

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]