public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
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...


      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).