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