From: Jon Turney <jon.turney@dronecode.org.uk>
To: Brian Inglis <Brian.Inglis@Shaw.ca>,
"cygwin-apps@cygwin.com" <cygwin-apps@cygwin.com>
Subject: Re: scallywag mingw64 complain cross-tools not installed before installs decided
Date: Tue, 16 May 2023 16:54:37 +0100 [thread overview]
Message-ID: <35aed14c-b786-996f-55eb-ecf9b59c9da8@dronecode.org.uk> (raw)
In-Reply-To: <7de1702b-3869-ad36-dfaa-539b582969b9@Shaw.ca>
On 16/05/2023 05:58, Brian Inglis via Cygwin-apps wrote:
> Just recently noticed this has been happening as builds succeeded; see:
>
> https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-nghttp2&status=build+succeeded&user=Brian+Inglis&id=6354
> https://github.com/cygwin/scallywag/actions/runs/4968984196
>
> https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-nghttp2&status=build+succeeded&user=Brian+Inglis&id=5367
> https://github.com/cygwin/scallywag/actions/runs/4225550616
>
> scallywag: repository contains cygport mingw64-x86_64-nghttp2.cygport
> scallywag: cygport vars failed, exit status 1
> scallywag: /usr/share/cygport/cygclass/cross.cygclass: line 142:
> x86_64-w64-mingw32-gcc: command not found
> *** ERROR: This package requires x86_64-w64-mingw32 binutils and gcc
>
> scallywag:
> scallywag: parsing cygport
> /cygdrive/d/a/scallywag/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2.cygport
This isn't actually a new problem, although it's probably more clearly
reported now.
The problem is that some cygport classes perform environment checks in
free code (not as part of any function) e.g. 'inherit cross' immediately
checks for the CROSS_HOST complier.
This interacts badly with cygport commands which aren't actually one of
the build steps, and particularly with 'cygport vars BUILD_REQUIRES'
(which scallywag wants to use to determine what packages need to be
installed)
To make things (usually) work in this situation, scallywag falls back to
trying to parse the cygport file to extract variables (as we did before
'cygport vars' was implemented) - which succeeds because it doesn't try
to execute the cygport, but is much less reliable in terms of giving
correct answers, since it only understands literal string assignments,
and can't understand e.g. shell variable expansions etc.
The real fix is for someone to rearrange things in cygport, so that
these checks only occur before the build-steps which they are actually
prerequisites for, but that hasn't happened yet...
prev parent reply other threads:[~2023-05-16 15:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 4:58 Brian Inglis
2023-05-16 15:54 ` Jon Turney [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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35aed14c-b786-996f-55eb-ecf9b59c9da8@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=Brian.Inglis@Shaw.ca \
--cc=cygwin-apps@cygwin.com \
/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.
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).