unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: goodoldpaul@autistici.org
Cc: 38228-done@debbugs.gnu.org
Subject: bug#38228: Fwd: [PATCH] gnu: boost: Build with python3
Date: Wed, 08 Jan 2020 22:11:17 +0100	[thread overview]
Message-ID: <87pnft1wne.fsf@devup.no> (raw)
In-Reply-To: <8b0f0ae38588baf77c1e43d1690f3dd4@autistici.org>

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

goodoldpaul@autistici.org writes:

> Hello Marius,
> I apologize for taking so long: the end of the semester is near and my 
> time is a little limited.

No worries.  :-)

> I'm attaching the two patches. As you said the one that parameterizes 
> the python version of boost-with-python3 must be applied to master, the 
> other one to core-updates.

Excellent!  I went ahead and adjusted it to work with the Boost
cross-compilation changes on 'core-updates', as well as simplified it a
little:

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=2ac164a8107dbb07ba1ed29986859d3e936f795a

>>> The patch builds boost with python3 and parameterizes the python
>>> version, as Efraim suggested. I built it successfully on core updates.
>>> When I tried building Epour on core-updates and saw that Guix was
>>> starting to build Bash 5.0 I renounced (:D) and I built it on master
>>> with boost-with-python3 .
>> 
>> In general, working on the 'core-updates' branch requires a fairly
>> powerful computer (and lots of time), sorry about that!
>> 
>>> Libtorrent-rasterbar seems to build fine on master but some tests fail
>>> to pass and they all seem to be network related but then again this is
>>> torrent we are talking about. I didn't investigate further but I 
>>> attach
>>> the log.
>> 
>> Strange.  I suppose these tests are not run when using Boost + Python 
>> 2?
>> In any case we don't have to worry about that just yet ;-)
>
> I gave another look at Libtorrent-rasterbar and I noticed that it 
> depends directly on python2, so the answer to the failing tests could be 
> that upgrading both boost and the python version ( as was done in 
> Efraim's code that I used last time to test boost-with-python3 )  broke 
> something that a closer look to the failing tests could figure out.
>
> Right now I tested the upgraded version without problems by building the 
> following ( randomly selected) packages: innoextract, swig, libarea, 
> pbbam, cgal, openimageio. If you have a better idea of what must be 
> tested please tell me and I'll do some more tests.

Thanks for testing!  I had to adjust 'Vigra' to work with Python 3, but
it was straightforward:

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=a82e6faa8b993d1f3b47a8bd22c4509f7cae7ec1

>>> From 91a25fb143ad0e2e20e8ddadea0c0610849adf92 Mon Sep 17 00:00:00 2001
>>> From: Giacomo Leidi <goodoldpaul@autistici.org>
>>> Date: Tue, 12 Nov 2019 00:24:49 +0100
>>> Subject: [PATCH] gnu: boost: Build with python3.
>>> 
>>> * gnu/packages/boost.scm (boost):
>>> [arguments]: Parameterize python version.
>>> [native-inputs]: Use python3.
>> 
>> [...]
>> 
>>>      (arguments
>>> -     `(#:tests? #f
>>> +     `(#:modules ((guix build gnu-build-system)
>>> +                  (guix build utils)
>>> +                  (srfi srfi-1))
>> 
>> If you add (guix build python-build-system) in there ...
>
> [...]
>
>>>           (replace 'configure
>>>             (lambda* (#:key inputs outputs #:allow-other-keys)
>>>               (let ((icu (assoc-ref inputs "icu4c"))
>>> +                   (python (assoc-ref inputs "python"))
>>> +                   (python-version
>>> +                    (take (string-split ,(package-version python) 
>>> #\.) 2))
>> 
>> ... then you can use (python-version (python-version python)) here and
>> below.
>
> I did add python-build-system to #:modules, but Guix kept complaining 
> that python-build-system was not importable until I added
>
> #:imported-modules ((guix build python-build-system)
>                             ,@%gnu-build-system-modules)
>
> Do you happen to have any idea of the differences from 
> #:imported-modules and #:modules? And why was using only 
> gnu-build-system possible also without adding it to #:imported-modules?

Caleb explains it very well here:

https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00105.html

> Or even better: is there any kind of documentation of the arguments and 
> keywords and return values of Guix's functions? Something like this 
> https://flask.palletsprojects.com/en/1.1.x/api/ .

Unfortunately no, but documenting parts of the Guix API is being
discussed.  The procedures are typically documented in the source code
though, so 'git grep' is the best tool for now.  :-/

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

      reply	other threads:[~2020-01-08 21:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 10:59 [bug#38128] [PATCH] gnu: Add boost-with-python3 goodoldpaul
2019-11-10 21:50 ` bug#38128: " Marius Bakke
2019-11-11  9:36   ` [bug#38128] " Efraim Flashner
2019-11-12  0:06     ` goodoldpaul
2019-11-16  9:04       ` [bug#38228] Fwd: [PATCH] gnu: boost: Build with python3 goodoldpaul
2019-11-20  0:01         ` Marius Bakke
2019-12-09 11:24           ` goodoldpaul
2020-01-08 21:11             ` Marius Bakke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pnft1wne.fsf@devup.no \
    --to=mbakke@fastmail.com \
    --cc=38228-done@debbugs.gnu.org \
    --cc=goodoldpaul@autistici.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).