Cygport user guide

Cygport user guide

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 339 bytes --]

In the process of making my cygport file for wxPython 4, I've quite
quickly found that I don't understand how cygport works all that well.

The reference guide is extremely useful, but it's a bit tricky finding
which things are useful/relevant. Is there a user guide for
Cygport/could we make one (I'd be happy to help)?

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Cygport user guide

[marco atzeri]

On Tue, Jun 9, 2020 at 3:23 PM Hamish McIntyre-Bhatty via Cygwin-apps  wrote:
>
> In the process of making my cygport file for wxPython 4, I've quite
> quickly found that I don't understand how cygport works all that well.
>
> The reference guide is extremely useful, but it's a bit tricky finding
> which things are useful/relevant. Is there a user guide for
> Cygport/could we make one (I'd be happy to help)?
>
> Hamish
>

I suspect the user base is too small to justify the effort and I am afraid every
major package needs a different approach.
My octave and all other math programs know-how does not apply to the
python effort I am working on ;-)

From my side, I mainly learned by looking at Yaakov's packages as guidelines.

Any specific argument are you looking for ?

Regards
Marco

Re: Cygport user guide

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 901 bytes --]

On 09/06/2020 16:55, marco atzeri wrote:

> I suspect the user base is too small to justify the effort and I am afraid every
> major package needs a different approach.
> My octave and all other math programs know-how does not apply to the
> python effort I am working on ;-)
>
> From my side, I mainly learned by looking at Yaakov's packages as guidelines.
>
> Any specific argument are you looking for ?
>
> Regards
> Marco

Ah I see, that is fair enough.

That's how I'm learning too - glad I'm not the only one who gets a bit
confused at times :)

I was looking for information on PYTHON3_SITELIB but I have since worked
out that it always just points to Python 3.6's sitelib folder. Still
raises the question of how to handle building libraries/modules for
py3.7 and 3.8, but I guess most will wait until 3.7 or 3.8 becomes the
default version (?).

Thanks,

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Cygport user guide

[Doug Henderson]

On Tue, 9 Jun 2020 at 09:56, marco atzeri via Cygwin-apps
<cygwin-apps@cygwin.com> 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.

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.

Thoughts?

Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

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