Cygport user guide

[Jon Turney]

On 09/06/2020 23:49, Doug Henderson via Cygwin-apps wrote:
> On Tue, 9 Jun 2020 at 09:56, marco atzeri via Cygwin-apps
> <cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org> wrote:
>> On Tue, Jun 9, 2020 at 3:23 PM Hamish McIntyre-Bhatty via Cygwin-apps  wrote:
>>> <snip>
>>
>> I suspect the user base is too small to justify the effort and I am afraid every
>> major package needs a different approach.
> 
>   I find that I need an overview document to get me back up to speed
> when I haven't used cygport for a while. The existing document, which
> describes a very simple cygport file is a start, but stops way too
> soon. I'd like to see a high level description of how cygport works.
> If reading about some other packaging system would be helpful, I would
> like to see a link to such documentation.

I guess this is talking about the example in 
https://cygwin.com/packaging-contributors-guide.html?

Yes, a few worked examples or top FAQ 'How do I do X with cygport?' 
would be a great addition there.

Ideally as patches to https://cygwin.com/git/?p=cygwin-htdocs.git, but I 
realize writing raw HTML is so last millennium, so I will also accept 
words in an email. :)

> Recently, I used cygport to automate the building of an app that I
> will probably never ITA (it compiles cleanly, runs fine, but does not
> actually work on Windows). I knew it used cmake, but I had to grep
> through setup.ini to find the packages that had a development
> dependency on cmake, and get the source packages to figure out how
> their cygport files worked. (It's just a one line change, but it needs
> to be the right line!).
> 
> There is generated documentation, but it needs to be fleshed out to be
> useful. Doing that, in an incremental fashion, might be a route to
> make more helpful documentation. Uncharitably, that sounds like asking
> one person to take on the bulk of the work. Perhaps those of us that
> occasionally have to dig into the cygport code could git clone cygport
> and make a personal branch to add some few words to any functions we
> happen to study. Hopefully pull requests for comment only changes
> should be easy to approve and merge.

Yes, please.