all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Christopher Baines <mail@cbaines.net>
Cc: 60847@debbugs.gnu.org
Subject: [bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system.
Date: Tue, 07 Mar 2023 14:03:27 -0500	[thread overview]
Message-ID: <87a60owfi8.fsf@gmail.com> (raw)
In-Reply-To: <87jzzsr3tx.fsf@cbaines.net> (Christopher Baines's message of "Tue, 07 Mar 2023 15:05:47 +0000")

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi Ludo!
>>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello,
>>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> +++ b/guix/packages.scm
>>>> @@ -1864,28 +1864,30 @@ (define* (bag->derivation bag #:optional context)
>>>
>>> […]
>>>
>>>> +  (let ((builder-name (procedure-name (bag-build bag))))
>>>> +    (if (or (bag-target bag)
>>>> +            (eq? 'pyproject-build builder-name))
>>>> +        (bag->cross-derivation bag)
>>>
>>> This one part is a showstopper to me, for two reasons:
>>>
>>>   1. We cannot rely on ‘procedure-name’ (it’s a debugging aid and it’s
>>>      not guaranteed to return something useful).
>>>
>>>   2. Special-casing build systems here is not okay: the bag and build
>>>      system abstractions exist to maintain separation of concerns.
>>>
>>> I understand there’s an actual bug to fix and the desire to fix a more
>>> common issue, but I think this one approach is not the way forward.
>>>
>>> I hope that makes sense!
>>
>> I agree this is not "pretty", but it would be a "temporary" kludge until
>> all the build systems can be migrated (and the package adjusted for) the
>> "new" way, which is: native-inputs and inputs always co-exist, whether
>> the build is a native one or a cross one.
>>
>> In light of this, it seems OK to test the water with a not so
>> significant build system (only a handful of package relies on
>> pyproject-build-system thus far).  When all the build systems will have
>> been migrated to the new way (a too big undertaking to be done in one
>> shot), this kludge can be removed.
>>
>> Otherwise, could you offer a concrete suggestion as the way forward?  I
>> appreciate the "that's not the way", but stopping short of suggesting a
>> better alternative leaves me wanting more :-).
>
> I think it would be clearer to see other potential ways forward if the
> end goal was more clearly articulated.
>
> Guessing at that here from the changes proposed to guix/packages.scm,
> once all build systems are adjusted, cross derivations will be produced
> for all bags, regardless of whether there's a target.
>
> That doesn't make much sense to me. One explaination is that the current
> naming is confusing when thinking about this goal, so maybe
> bag->cross-derivation happens to do what you want it to do in all
> circumstances, even when target is #f?

Thanks for tipping in.  The end goal is to avoid loosing the information
of which inputs are native (build inputs) vs regular in the bag, and yes
bag->cross-derivation allows that.  It appears to me the distinction in
the bag representations (native vs cross) was originally perceived
useful as some kind of optimization (there's less variables to worry
about, and we can squash the inputs/search-paths together, since they're
all native anyway), but this information (currently discarded) ends up
being very useful even on the build side (to wrap only the target
inputs, say, and not all the native/build inputs).

So yes, the change long term would be to integrate the
bag->cross-derivation logic into bag->derivation, at which point it
would be unified for any type of build (the bag representation would be
shared between native and cross builds).

When authoring packages, we'd no longer see the odd idiom '(or
native-inputs inputs)' which results from this implementation detail;
instead we'd always have access to both 'native-inputs' and 'inputs'.

I hope that helps understanding the rationale.

-- 
Thanks,
Maxim




  reply	other threads:[~2023-03-07 19:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-16  4:04 [bug#60847] [PATCH 0/5] Enable cross-compilation for the pyproject-build-system Maxim Cournoyer
2023-01-16  5:01 ` [bug#60847] [PATCH 0/1] " Maxim Cournoyer
2023-01-16  5:01   ` [bug#60847] [PATCH 1/1] build: Enable cross-compilation for pyproject-build-system Maxim Cournoyer
2023-01-23 13:32 ` [bug#60847] [PATCH v2 0/1] Enable cross-compilation for the pyproject-build-system Maxim Cournoyer
2023-01-23 13:32   ` [bug#60847] [PATCH v2 1/1] build: Enable cross-compilation for pyproject-build-system Maxim Cournoyer
2023-03-06 17:04     ` [bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system Ludovic Courtès
2023-03-07 14:08       ` Maxim Cournoyer
2023-03-07 15:05         ` Christopher Baines
2023-03-07 19:03           ` Maxim Cournoyer [this message]
2023-03-07 19:26             ` Christopher Baines
2023-03-10 14:13               ` Maxim Cournoyer
2023-03-10  8:57         ` Ludovic Courtès
2023-03-10 14:21           ` Maxim Cournoyer
2023-03-10 17:00             ` Ludovic Courtès
2023-03-12  4:05               ` Maxim Cournoyer
2023-03-12  4:05               ` Maxim Cournoyer
2023-03-06 22:56     ` jgart via Guix-patches via
2023-03-07  0:25     ` jgart via Guix-patches via
2023-01-24  2:05   ` [bug#60847] [PATCH v2 1/1] build: Enable cross-compilation for pyproject-build-system jgart via Guix-patches via

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

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

  git send-email \
    --in-reply-to=87a60owfi8.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=60847@debbugs.gnu.org \
    --cc=mail@cbaines.net \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.