Re: cygport build/package issues

Am 20.09.2025 um 19:07 schrieb Thomas Wolff via Cygwin-apps:
>
> Am 20.09.2025 um 00:37 schrieb Brian Inglis via Cygwin-apps:
>> On 2025-09-19 10:24, Thomas Wolff via Cygwin-apps wrote:
>>>
>>>
>>> Am 18.09.2025 um 05:32 schrieb Brian Inglis via Cygwin-apps:
>>>> On 2025-09-16 15:42, Thomas Wolff via Cygwin-apps wrote:
>>>>> questions for a new package:
>>>>>  * Is there a way to specify a git clone for download rather than 
>>>>> a download URI?
>>>>
>>>> See:
>>>>
>>>>     https://cygwin.github.io/cygport/git_cygclass.html
>>>>
>>>> for example:
>>>>
>>>>     GIT_URI=https://github.com/$NAME/$NAME
>>>>     GIT_BRANCH=$NAME
>>>>     GIT_TAG=v$VERSION
>>>>     GIT_REV=
>>>>
>>>>     inherit git
>>>>
>>>>> * I have a build script (which also downloads actual sources).
>>>>>   Is there a cygwin function to invoke it or do I have to put it 
>>>>> into src_compile and abuse the compile step for it? 
>>>> Please avoid that as enough abuse of cygport functions is normally 
>>>> required to handle non-standard package processing. ;^>
>>>>
>>>> See:
>>>>
>>>>     https://cygwin.github.io/cygport/toc_index.html
>>>>
>>>> Convert the build script to cygport functions; see:
>>>>
>>>>     https://cygwin.github.io/cygport/compilers_cygpart.html
>>>>
>>>>     https://cygwin.github.io/cygport/src_install_cygpart.html
>>>>
>>>>     https://cygwin.github.io/cygport/src_postinst_cygpart.html
>>>>
>>>>     https://cygwin.github.io/cygport/pkg_pkg_cygpart.html
>>>>
>>>>     https://cygwin.github.io/cygport/cygport_testsuite_functions.html
>>>>
>>>> Standard top level functions:
>>>>
>>>>     src_compile() {
>>>>             cd ${S}
>>>>             cygautoreconf
>>>>             cd ${B}
>>>>             cygconf
>>>>             cygmake
>>>>     }
>>>>
>>>>     src_install() {
>>>>             cd ${B}
>>>>             cyginstall
>>>>     }
>>>>
>>>>     src_test() {
>>>>             cd ${B}
>>>>             cygtest
>>>>     }
>>>>
>>>> Some higher level functions:
>>>>
>>>>     cygautoreconf
>>>>     cygcmake
>>>>     cygconf
>>>>     cyginstall
>>>>     cygmake
>>>>     cygmeson
>>>>     cygninja
>>>>     cygqmake3
>>>>     cygqmake4
>>>>     cygqmake5
>>>>     cygtest
>>>>
>>>> others:
>>>>
>>>>     https://cygwin.github.io/cygport/cygport_general_functions.html
>>>>
>>>> and there are plenty of classes with overloads, if those apply:
>>>>
>>>>     https://cygwin.github.io/cygport/cygport_cygclasses.html
>>>>
>>>>     https://cygwin.github.io/cygport/cygport_overloads.html
>>>>
>>>> For any commands which do not map to appropriate cygport functions, 
>>>> or are not done automatically, you can put those into a Makefile 
>>>> and invoke it with cygmake.
>>>>
>>>>> * Is there a way to specify files (like the build script in this 
>>>>> case)
>>>>>   to be included in the source package?
>>>> SRC_URI+=" https://..."
>>>> SRC_URI+=" filename"
>>>>
>>>> The intent is for all packages to be built using cygport to support 
>>>> CI and any policies and approaches desired, and automate a *LOT* of 
>>>> any grunt work commonly required!
>>>>
>>>> The desire is to eventually have validated deployments only via 
>>>> cygport, scallywag, and calm, or successors.
>>>>
>>>> Post the build script, or a link to the package definition, spec, 
>>>> ebuild, etc. on other distros or sites, for advice, suggestions, 
>>>> and help porting it to cygport.
>>>>
>>> Thanks for the SRC_URI+= hint. The GIT_URI, GIT_TAG hint did not 
>>> work, nothing was downloaded. Also it's a huge repository and I'd 
>>> prefer shallow clone (-- depth 1) and sparse checkout.
Actually, the SRC_URI trick fixes the package step but spoils the prep step:
/bin/cp: failed to access 'emojis-noto-v2.051-1.noarch': No such file or 
directory
*** ERROR: cp -t emojis-noto-v2.051-1.noarch getnoto failed

Bundling a build script with the cygport does not seem to be supported. 
It could be injected as a patch perhaps.
As the two scripts are actually also part of mintty, I guess I'll add 
them as a downloadable source.

>>
>> Cygport git cygclass defaults to --depth 1, and retries without if 
>> that fails because shallow clones are not supported by the upstream, 
>> after issuing a message to that effect.
>>
>>> I've uploaded a source package of my proposed package to 
>>> http://towo.net/cygwin/ emojis-noto-v2.048-1-src.tar.xz for 
>>> consideration.
>>
>> Did you notice the `inherit git` *AFTER* the definitions hint above?
> No, thanks. However, that still does not give me sparse (partial) 
> checkout. Also it seems to stall after checkout:
> git checkout tags/v2.051
> Updating files: 100% (20100/20100), done.
> HEAD is now at 8998f5dd Merge pull request #515 from googlefonts/e17
> - then nothing; waited for 5 min.
>
>>
>>     https://cygwin.github.io/cygport/git_cygclass.html#git.cygclass
>>
>> Also `inherit font` gives you font cygclass functions to store fonts 
>> in the appropriate places for use by *ALL* Cygwin apps newer than 
>> those supporting only legacy Adobe types.
> I assigned this package to the Fonts category but it's not really a 
> font...
>
>>
>>     https://cygwin.github.io/cygport/git_cygclass.html#git.cygclass
>>
>> Note the existing package, whose cygport would need some tweaks to 
>> get up to date since 2017:
>>
>>     https://cygwin.com/cgit/cygwin-packages/noto-emoji-fonts
> My proposed package does not replace the other one; it does not 
> provide the font but the emoji graphics (.png files) as used by mintty.
>
>>
>> Release v2.048 adds the Syria flag update to Unicode 16.0: you should 
>> be accessing tag v2.051 for Unicode 17 Emoji (mk1).
>>
>> For comparison, see the Fedora spec for latest branch build F43 
>> (currently == rawhide == main):
>>
>> https://src.fedoraproject.org/rpms/google-noto-emoji-fonts/blob/f43/f/google-noto-emoji-fonts.spec 
>>
>>