Re: Scallywag glitch with texlive-collection-* packages

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2020-09-14 23:34, ASSI wrote:
> Brian Inglis writes:
>> Any changes made or needed in cygport or scallywag for mingw64 packages?
>> I've rebuilt and reuploaded both Mingw curl noarches to see if they make it.
> 
> If you're just trying out things push to the playground branch and
> iterate it there until it works.  You can force-push to this branch and
> delete it afterwards if you want.

I just rebuilt all packages locally as release 2 and compared with the release 1
config and build logs to ensure the results were identical other than the
release number, before renumbering the cygport release back to 1 and committing
and pushing the cygport updates to git-cygwin-packages.

> You still haven't added the necessary BUILD_REQUIRES correctly.  Btw,

AFAIR multi-line BUILD_REQUIRES strings with and without \ at EoL caused
problems, so I have added a series of += statements to create that and DEPEND in
the latest cygport pushes to git-cygwin-packages, and align all 3 cygports as
much as possible for ease of comparison and maintenance (using gvimdiff).

> ZStandard is available both natively and for mingw64 in Cygwin.

Good suggestion, as it is picked up automatically by Cygwin curl config, but
although everything appears to be the same for zlib and zstd, other than zstd
missing a default sharedlibdir definition in zstd.pc, that is not found in the
mingw64 config which fails:

configure:21544: checking for x86_64-w64-mingw32-pkg-config
configure:21575: result: /usr/bin/x86_64-w64-mingw32-pkg-config
configure:21644: checking for zlib options with pkg-config
configure:21658: result: found
configure:21723: checking for zlib.h
configure:21723: result: yes
configure:21811: found both libz and libz.h header
configure:22106: checking for x86_64-w64-mingw32-pkg-config
configure:22137: result: /usr/bin/x86_64-w64-mingw32-pkg-config
configure:22206: checking for libzstd options with pkg-config
configure:22220: result: found
configure:22253: checking for ZSTD_createDStream in -lzstd
configure:22284: result: no
configure:22298: checking for zstd.h
configure:22298: result: no
configure:22318: error: libzstd was not found where specified!

As I am new to mingw64 packaging, any suggestions for things to try or tweaks
for mingw64 build are welcome.
Do I need to cross_de/sysrootize zstd.pc or something?

$ head -n19 /usr/lib/pkgconfig/*z???*.pc
==> /usr/lib/pkgconfig/libzstd.pc <==
#   ZSTD - standard compression algorithm
#   Copyright (C) 2014-2016, Yann Collet, Facebook
#   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: zstd
Description: fast lossless compression algorithm library
URL: http://www.zstd.net/
Version: 1.4.5
Libs: -L${libdir} -lzstd
Cflags: -I${includedir}

==> /usr/lib/pkgconfig/zlib.pc <==
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
sharedlibdir=/usr/lib
includedir=/usr/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}

>> I found that for cygport NAME must be a hardcoded constant string not requiring
>> script evaluation; hopefully other content is evaluated in the script context
>> and does not also require to be hardcoded constants.
> 
> You need to lose that $XARCH monkey business as well.  Scallywag just
> looks at the file, it doesn't evaluate anything.

That variable makes it easier for me to align and copy/paste changes between
cygport scripts with fewer errors, which is why I added it, as I could not come
up with a meaningful name to call the mingw64-$XARCH prefix, and also worried
about possibly conflicting with cygport variables.

As not all variables can be specified as multi-line constants, and I am
uncomfortable specifying variables in lines hundreds of bytes long, they need to
be composed with short lines using +=, and not evaluating may lead to incorrect
results.

[TL;DR: I got used in (macro) assemblers and earlier (strict) languages to
abstracting out very granular architectural features and data, definitions, and
patterns into common specification header definitions distinct from the abstract
implementation in code, and that is still my preferred personal development
style, subject to project variations: that may annoy others as much as my seeing
others using any manifest constant values (other than 0, 1, various nulls) in code!]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]