[ITA] wxWidgets3.0

[ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

Hi there,

Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
in new patches from Fedora, but I can't find
mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
anywhere. Does anyone happen to have a copy of this?

My hope is that it is no longer needed, but obviously I can't confirm
that without actually having the patch. I haven't got any files uploaded
yet because I'm doing a test build. If anyone has a copy of that
patch/knows where to find it please let me know.

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: [ITA] wxWidgets3.0

[Lemures Lemniscati]

On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps
> Hi there,
> 
> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
> in new patches from Fedora, but I can't find
> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
> anywhere. Does anyone happen to have a copy of this?
> 
> My hope is that it is no longer needed, but obviously I can't confirm
> that without actually having the patch. I haven't got any files uploaded
> yet because I'm doing a test build. If anyone has a copy of that
> patch/knows where to find it please let me know.
> 
> Hamish
> 

Hi!

You can get them from one of the current src packages.

List of src files: https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src
Package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/

Regards,

Lem

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote:
> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps
>> Hi there,
>>
>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
>> in new patches from Fedora, but I can't find
>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
>> anywhere. Does anyone happen to have a copy of this?
>>
>> My hope is that it is no longer needed, but obviously I can't confirm
>> that without actually having the patch. I haven't got any files uploaded
>> yet because I'm doing a test build. If anyone has a copy of that
>> patch/knows where to find it please let me know.
>>
>> Hamish
>>
> Hi!
>
> You can get them from one of the current src packages.
>
> List of src files: https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src
> Package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/
>
> Regards,
>
> Lem

Excellent, thanks :)

I'll post again when I've got builds and have improved the cygport file
(this one doesn't have build dependencies).

It takes about 3-4 hours per build, somehow, so it might be a little
while, but we'll see :)

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: [ITA] wxWidgets3.0

[Brian Inglis]

On 2020-10-17 07:17, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote:
>> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps
>>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
>>> in new patches from Fedora, but I can't find
>>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
>>> anywhere. Does anyone happen to have a copy of this?
>>>
>>> My hope is that it is no longer needed, but obviously I can't confirm
>>> that without actually having the patch. I haven't got any files uploaded
>>> yet because I'm doing a test build. If anyone has a copy of that
>>> patch/knows where to find it please let me know.

>> You can get them from one of the current src packages.
>> List of src files: https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src
>> Package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/

> Excellent, thanks :)
> 
> I'll post again when I've got builds and have improved the cygport file
> (this one doesn't have build dependencies).
> 
> It takes about 3-4 hours per build, somehow, so it might be a little
> while, but we'll see :)

Those mirrors should be part of cygport SRC_URI or PATCH_URI and will be
retrieved on download.

Portage is gentoo equivalent on which cygport is based and that patch hits some
make and bake file and translation sources as part of a patchset series:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16e67f0678b264a04e96954a4593ddac3a9a32d

including also:

https://dev.gentoo.org/~leio/distfiles/wxGTK-3.0.3_p20180104.tar.xz

where you will have to figure out if you need to doenload and apply patches to
their sources or make a similar change to get the equivalent effect in your
cygport.

-- 
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 binary units and prefixes, physical quantities in SI.]

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 17/10/2020 16:04, Brian Inglis wrote:
> On 2020-10-17 07:17, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote:
>>> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps
>>>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
>>>> in new patches from Fedora, but I can't find
>>>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
>>>> anywhere. Does anyone happen to have a copy of this?
>>>>
>>>> My hope is that it is no longer needed, but obviously I can't confirm
>>>> that without actually having the patch. I haven't got any files uploaded
>>>> yet because I'm doing a test build. If anyone has a copy of that
>>>> patch/knows where to find it please let me know.
>>> You can get them from one of the current src packages.
>>> List of src files: https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src
>>> Package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/
>> Excellent, thanks :)
>>
>> I'll post again when I've got builds and have improved the cygport file
>> (this one doesn't have build dependencies).
>>
>> It takes about 3-4 hours per build, somehow, so it might be a little
>> while, but we'll see :)
> Those mirrors should be part of cygport SRC_URI or PATCH_URI and will be
> retrieved on download.
>
> Portage is gentoo equivalent on which cygport is based and that patch hits some
> make and bake file and translation sources as part of a patchset series:
>
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16e67f0678b264a04e96954a4593ddac3a9a32d
>
> including also:
>
> https://dev.gentoo.org/~leio/distfiles/wxGTK-3.0.3_p20180104.tar.xz
>
> where you will have to figure out if you need to doenload and apply patches to
> their sources or make a similar change to get the equivalent effect in your
> cygport.
>
Thanks Brian, I'll look into those.

It gave a 404 trying to download that patch, but not a problem because I
have it now. I'll look around and see if I can use those other ones you
sent, or if there are more patches in any more current Gentoo package.

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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 19/10/2020 16:31, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 17/10/2020 16:04, Brian Inglis wrote:
>> On 2020-10-17 07:17, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote:
>>>> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps
>>>>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
>>>>> in new patches from Fedora, but I can't find
>>>>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
>>>>> anywhere. Does anyone happen to have a copy of this?
>>>>>
>>>>> My hope is that it is no longer needed, but obviously I can't confirm
>>>>> that without actually having the patch. I haven't got any files uploaded
>>>>> yet because I'm doing a test build. If anyone has a copy of that
>>>>> patch/knows where to find it please let me know.
>>>> You can get them from one of the current src packages.
>>>> List of src files: https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src
>>>> Package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/
>>> Excellent, thanks :)
>>>
>>> I'll post again when I've got builds and have improved the cygport file
>>> (this one doesn't have build dependencies).
>>>
>>> It takes about 3-4 hours per build, somehow, so it might be a little
>>> while, but we'll see :)
>> Those mirrors should be part of cygport SRC_URI or PATCH_URI and will be
>> retrieved on download.
>>
>> Portage is gentoo equivalent on which cygport is based and that patch hits some
>> make and bake file and translation sources as part of a patchset series:
>>
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16e67f0678b264a04e96954a4593ddac3a9a32d
>>
>> including also:
>>
>> https://dev.gentoo.org/~leio/distfiles/wxGTK-3.0.3_p20180104.tar.xz
>>
>> where you will have to figure out if you need to doenload and apply patches to
>> their sources or make a similar change to get the equivalent effect in your
>> cygport.
>>
> Thanks Brian, I'll look into those.
>
> It gave a 404 trying to download that patch, but not a problem because I
> have it now. I'll look around and see if I can use those other ones you
> sent, or if there are more patches in any more current Gentoo package.
>
> Hamish

Okay, new patches reviewed and BUILD_DEPENDS is sorted.

I've heard a new CI tool mentioned here (AppVeyor?). Is there a way I
can use that to test my packaging/build-depends once this local build is
finished?

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: [ITA] wxWidgets3.0

[Brian Inglis]

On 2020-10-21 07:57, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 19/10/2020 16:31, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 17/10/2020 16:04, Brian Inglis wrote:
>>> On 2020-10-17 07:17, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>>> On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote:
>>>>> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps
>>>>>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled
>>>>>> in new patches from Fedora, but I can't find
>>>>>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch
>>>>>> anywhere. Does anyone happen to have a copy of this?
>>>>>>
>>>>>> My hope is that it is no longer needed, but obviously I can't confirm
>>>>>> that without actually having the patch. I haven't got any files uploaded
>>>>>> yet because I'm doing a test build. If anyone has a copy of that
>>>>>> patch/knows where to find it please let me know.
>>>>> You can get them from one of the current src packages.
>>>>> List of src files: https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src
>>>>> Package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/
>>>> Excellent, thanks :)
>>>>
>>>> I'll post again when I've got builds and have improved the cygport file
>>>> (this one doesn't have build dependencies).
>>>>
>>>> It takes about 3-4 hours per build, somehow, so it might be a little
>>>> while, but we'll see :)
>>> Those mirrors should be part of cygport SRC_URI or PATCH_URI and will be
>>> retrieved on download.
>>>
>>> Portage is gentoo equivalent on which cygport is based and that patch hits some
>>> make and bake file and translation sources as part of a patchset series:
>>>
>>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16e67f0678b264a04e96954a4593ddac3a9a32d
>>>
>>> including also:
>>>
>>> https://dev.gentoo.org/~leio/distfiles/wxGTK-3.0.3_p20180104.tar.xz
>>>
>>> where you will have to figure out if you need to doenload and apply patches to
>>> their sources or make a similar change to get the equivalent effect in your
>>> cygport.
>>>
>> Thanks Brian, I'll look into those.
>>
>> It gave a 404 trying to download that patch, but not a problem because I
>> have it now. I'll look around and see if I can use those other ones you
>> sent, or if there are more patches in any more current Gentoo package.
>>
>> Hamish
> 
> Okay, new patches reviewed and BUILD_DEPENDS is sorted.
> 
> I've heard a new CI tool mentioned here (AppVeyor?). Is there a way I
> can use that to test my packaging/build-depends once this local build is
> finished?

https://cygwin.com/pipermail/cygwin-apps/2020-October/040577.html

As you adopted the package, you will first have to do a clone in your Cygwin
cygport directory from:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/wxWidgets3.0.git

YMMV, but after cloning adopted packages, as I have a Cygwin ssh alias defined,
I setup my .git/config for each package like:

$ tail +0 .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
[remote "origin"]
        url = ssh://cygwin/git/cygwin-packages/curl.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = ssh://cygwin/git/cygwin-packages/curl
        merge = refs/heads/master

and run ssh-agent and ssh-add to provide my passphrase for uploads and pushes.
I believe you may use e.g. ssh://cygwin@cygwin.com/... instead.

If you are the original ITP packager, you have to init the package, set the
[remote "origin"], add and commit the cygport and any other files you want to
publish, then push to create the Cygwin repo.

I should now add [branch "playground"] entries to make testing appveyor CI
builds cleaner and easier, as I usually don't do this stuff enough to remember
how to do it, so I muddle through, and then forget what I need to add to my
notes on packaging.

-- 
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 binary units and prefixes, physical quantities in SI.]

Re: [ITA] wxWidgets3.0

[Achim Gratz]

Brian Inglis writes:
> I should now add [branch "playground"] entries to make testing appveyor CI
> builds cleaner and easier, as I usually don't do this stuff enough to remember
> how to do it, so I muddle through, and then forget what I need to add to my
> notes on packaging.

It's not necessary to keep playground as a local branch, just

git push origin master:playground

fix it up as you get the Ci results and then after everything works
there, push to master and delete the branch on the remote with

git push origin && git push origin :playground


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 21/10/2020 19:39, Achim Gratz wrote:
> Brian Inglis writes:
>> I should now add [branch "playground"] entries to make testing appveyor CI
>> builds cleaner and easier, as I usually don't do this stuff enough to remember
>> how to do it, so I muddle through, and then forget what I need to add to my
>> notes on packaging.
> It's not necessary to keep playground as a local branch, just
>
> git push origin master:playground
>
> fix it up as you get the Ci results and then after everything works
> there, push to master and delete the branch on the remote with
>
> git push origin && git push origin :playground
>
>
> Regards,
> Achim.

Excellent, thanks.

Unfortunately, the unit tests do not run correctly for me, but it seems
they were originally disabled by Yakkov, probably for this exact reason.

There are two test programs generated for both GTK2 and GTK3. One is a
commandline tool, and the other tests GUI elements and does things like
simulating mouse clicks and keyboard input. Please note that neither of
these compile unless I edit the makefile to remove the fswatcher
component (which doesn't build in Cygwin), I think it uses a kernel feature.

The cmdline one segfaults (both for GTK2 and GTK3), and a number of
tests fail, but unfortunately I cannot see which exact tests are failing
because I don't get to the summary before it segfaults. I'm not really
sure how to debug this, as I don't have much experience in C/C++
programming, and even less experience with using a debugger. Any good
tips/links?

The GTK2 GUI tests pass with only 2 failures, but there are 53 failures
for the GTK3 GUI tests.

If I can use a demo (eg the wxPython demo) and recursively go through
all the GUI elements verifying things work, would that be considered
good enough? I imagine this is probably what Yaakov did back when he
built the current wxwidgets packages. I'm not really satisfied with this
but I am not sure I have the skills to proceed further without help/advice.

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: [ITA] wxWidgets3.0

[ASSI]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Unfortunately, the unit tests do not run correctly for me, but it seems
> they were originally disabled by Yakkov, probably for this exact reason.

I believe many of the Gtk packages were either cross-compiled or
compiled on a machine without the GUI available, so I'd not expect the
tests to have been run for these.  Another problem is that GUI tests
more often than not than suffer from ATWIL syndrome and can't be run as
intended without major changes to the testsuite.

> The cmdline one segfaults (both for GTK2 and GTK3), and a number of
> tests fail, but unfortunately I cannot see which exact tests are failing
> because I don't get to the summary before it segfaults. I'm not really
> sure how to debug this, as I don't have much experience in C/C++
> programming, and even less experience with using a debugger. Any good
> tips/links?

Well, the first thing I'd check if it even picks up the libraries you
have just compiled.  If it fiddles with LD_LIBRARY_PATH that's your
first clue that it doesn't.  You might have to prepend the build
directories that have the libraries to PATH or even install the package
before running the tests.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 27/10/2020 13:16, ASSI wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> Unfortunately, the unit tests do not run correctly for me, but it seems
>> they were originally disabled by Yakkov, probably for this exact reason.
> I believe many of the Gtk packages were either cross-compiled or
> compiled on a machine without the GUI available, so I'd not expect the
> tests to have been run for these.  Another problem is that GUI tests
> more often than not than suffer from ATWIL syndrome and can't be run as
> intended without major changes to the testsuite.

Ah I see, this makes sense. How well the GUI tests run seems rather
inconsistent. I think there might be an alignment issue that's causing
so many of the GTK3 tests to fail.

>> The cmdline one segfaults (both for GTK2 and GTK3), and a number of
>> tests fail, but unfortunately I cannot see which exact tests are failing
>> because I don't get to the summary before it segfaults. I'm not really
>> sure how to debug this, as I don't have much experience in C/C++
>> programming, and even less experience with using a debugger. Any good
>> tips/links?
> Well, the first thing I'd check if it even picks up the libraries you
> have just compiled.  If it fiddles with LD_LIBRARY_PATH that's your
> first clue that it doesn't.  You might have to prepend the build
> directories that have the libraries to PATH or even install the package
> before running the tests.

I've already added the libraries to PATH when building, but thanks for
the suggestion. I did also have to remove the system wxwidgets install
even with that, because the unit tests kept trying to use that,
resulting in fork errors and other unpredictable behaviour. Any more
ideas? Honestly, I'm happy to test manually with the wxPython demo and
some wxwidgets test programs if that's considered good enough.

Another interesting thing is that I get the following messages when
running cygport install:

Warning: x was not linked with -Wl, --enable-auto-image-base

Is this anything to be alarmed about or not really an issue? The
libraries seem to work okay, at any rate.

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: [ITA] wxWidgets3.0

[Achim Gratz]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Another interesting thing is that I get the following messages when
> running cygport install:
>
> Warning: x was not linked with -Wl, --enable-auto-image-base
>
> Is this anything to be alarmed about or not really an issue? The
> libraries seem to work okay, at any rate.

I'm not sure if cygport actually fixes this up by changing the flags in
the DLL, but that means that the linker flags that cygport tries to
force are overwritten somewhere else.  Now, this is most likely CMake
you're dealing with, so the best of luck in figuring out where.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 28/10/2020 08:40, Achim Gratz wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> Another interesting thing is that I get the following messages when
>> running cygport install:
>>
>> Warning: x was not linked with -Wl, --enable-auto-image-base
>>
>> Is this anything to be alarmed about or not really an issue? The
>> libraries seem to work okay, at any rate.
> I'm not sure if cygport actually fixes this up by changing the flags in
> the DLL, but that means that the linker flags that cygport tries to
> force are overwritten somewhere else.  Now, this is most likely CMake
> you're dealing with, so the best of luck in figuring out where.
>
>
> Regards,
> Achim.

Okay thanks, I'll look into that shortly.

I'm getting near the stage where using the CI tool might be useful;
could someone hand over the package to me please so I can commit to the
git repo please?

Also of note, is the ridiculous amount of memory that seems to be needed
when compiling and linking wxWidgets (I needed to give 12GB to my VM!) -
will I crash the CI system if I try to build using it, or will it be
okay/not a disaster if it uses too much RAM and starts swapping?

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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 28/10/2020 08:40, Achim Gratz wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> Another interesting thing is that I get the following messages when
>> running cygport install:
>>
>> Warning: x was not linked with -Wl, --enable-auto-image-base
>>
>> Is this anything to be alarmed about or not really an issue? The
>> libraries seem to work okay, at any rate.
> I'm not sure if cygport actually fixes this up by changing the flags in
> the DLL, but that means that the linker flags that cygport tries to
> force are overwritten somewhere else.  Now, this is most likely CMake
> you're dealing with, so the best of luck in figuring out where.
>
>
> Regards,
> Achim.

Hmm, how does cygport do this?

I tried setting LDFLAGS (which was previously empty) to " -Wl,
--enable-auto-image-base" but that just broke the compiler.

I'm building again now with the hopes of seeing what the commandline to
the linker is, and hence hopefully finding it and maybe patching it in
the source, but there might be a better way.

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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

Ignore my previous message - whatever was wrong is now fixed. I didn't
change anything much so I think it was a dependency that had an issue
and was since recompiled.

64-bit build is done and seems to work fine. I'm testing it using the
samples, nearly all of which work, and new things that weren't in the
previous wxwidgets build now work (eg webview with webkit).

I need to finish my testing and then build for 32-bit Cygwin, but all
seems good.

When it's all done I'll email again with my cygport file attached and a
link to the file locations.

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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 11/11/2020 17:36, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Ignore my previous message - whatever was wrong is now fixed. I didn't
> change anything much so I think it was a dependency that had an issue
> and was since recompiled.
>
> 64-bit build is done and seems to work fine. I'm testing it using the
> samples, nearly all of which work, and new things that weren't in the
> previous wxwidgets build now work (eg webview with webkit).
>
> I need to finish my testing and then build for 32-bit Cygwin, but all
> seems good.
>
> When it's all done I'll email again with my cygport file attached and a
> link to the file locations.
>
> Hamish

Okay, I have successfully manually tested wxWidgets3.0 on both 32-bit
and 64-bit Cygwin, and I haven't found any significant issues. It also
seems to work with my existing wxPython build but I'm going to recompile
that anyway just to be sure and to get the new version number for
wxWidgets in the build.

The test packages are available for download at
https://www.hamishmb.com/files/cygwin-temp/ as usual, and my cygport
file is attached here.

Here's a quick summary of the changes I've made:

- Updated to wxWidgets 3.0.5.1 from 3.0.4.

- Added build dependencies.

- Evaluated lots of new patches (over 80), and found that nearly none of
them were needed (already patched in new source), so we only have a few
new patches.

- Updated the wxGTK collision patch for wxwidgets 3.0.5.1 as the old one
wouldn't apply.

- Use pushd and popd instead of cd in the cygport file.

- Enable automated unit tests in the cygport file (these currently do
work so I tested manually).

- Enable and test wxwebview with webkit (works fine in all configurations).

I'd like to use the AppVeyor CI tool to double check the build and build
dependencies, but the very high RAM usage during compilation (12GB!)
makes me think it might crash that system. Is it safe for me to proceed?
I really don't want to ruin someone's day by crashing the CI system(s).
I think I need a GTG before  can do this because I don't currently own
the package, but I'm not sure.

Finally, I'm going to keep these as test packages until I've got
wxPython build and tested against them, which will be maybe another week
or so depending on other priorities.

Any feedback is very welcome :)

Hamish


[-- Attachment #1.1.2: wxWidgets3.0.cygport --]
[-- Type: text/plain, Size: 6324 bytes --]

NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/"
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2"
SRC_DIR="wxWidgets-${VERSION}"
BUILD_REQUIRES="make xclock cppunit autoconf pkg-config gcc-core gcc-g++ doxygen graphviz libX11-devel libgtk2.0-devel libgtk3-devel libwebkitgtk1.0-devel libwebkitgtk1.0_0 libwebkitgtk3.0-devel libwebkitgtk3.0_0 libpng16 libpng-devel libjpeg-devel libjpeg8 libexpat1 libexpat-devel libiconv-devel libiconv libiconv2 libmspack0 libmspack-devel libnotify libnotify-devel libtiff6 libtiff-devel libXpm4 libXpm-devel libcogl20 libcogl-devel libEGL1 libEGL-devel libGL1 libGL-devel libGLU1 libGLU-devel libSDL2_2.0_0 libSDL2-devel libSDL2_image2.0_0 libSDL2_image-devel libSDL2_mixer2.0_0 libSDL2_mixer-devel libSDL2_net2.0_0 libSDL2_net-devel libSDL2_ttf2.0_0 libSDL2_ttf-devel zlib zlib-devel"
PATCH_URI="
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
	wxGTK3-3.0.5.1-collision.patch
	3.0.2-cygwin-auto-import.patch
	3.0.2-cygwin-dlopen.patch
	3.0.2-cygwin-unix.patch
	3.0.2-cygwin-gcc5.patch
	3.0.3-autoreconf.patch
	3.0.3-cygwin-ftm.patch
	0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"

slot=${PV_MAJ_MIN}

PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
           libwx_gtk2u3.0_0 libwx_gtk2u3.0-devel
           libwx_gtk3u3.0_0 libwx_gtk3u3.0-devel"
libwx_baseu3_0_0_SUMMARY="${SUMMARY} (base unicode runtime)"
libwx_baseu3_0_0_CONTENTS="
	--exclude=html
	usr/bin/cygwx_baseu*-3.0-0.dll
	usr/share/doc/${NAME}/
	usr/share/locale/*/LC_MESSAGES/wxstd30.mo
"
libwx_baseu3_0_devel_REQUIRES="libexpat-devel libiconv-devel zlib-devel"
libwx_baseu3_0_devel_CONTENTS="
	usr/bin/wxrc-3.0.exe
	usr/include/wx-3.0/
	usr/lib/libwx_baseu*-3.0.dll.a
	usr/lib/wx/config/base-unicode-3.0
	usr/lib/wx/include/base-unicode-3.0/
	usr/share/aclocal/wxwin-3.0.m4
	usr/share/bakefile/presets/wx30*
"
libwx_gtk2u3_0_0_SUMMARY="${SUMMARY} (GTK+2 unicode runtime)"
libwx_gtk2u3_0_0_CONTENTS="usr/bin/cygwx_gtk2u*-3.0-0.dll"
libwx_gtk2u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk2u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel libX11-devel"
libwx_gtk2u3_0_devel_CONTENTS="
	usr/lib/libwx_gtk2u*-3.0.dll.a
	usr/lib/wx/config/gtk2-unicode-3.0
	usr/lib/wx/include/gtk2-unicode-3.0/
"
libwx_gtk3u3_0_0_SUMMARY="${SUMMARY} (GTK+3 unicode runtime)"
libwx_gtk3u3_0_0_CONTENTS="usr/bin/cygwx_gtk3u*-3.0-0.dll"
libwx_gtk3u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk3u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel libX11-devel"
libwx_gtk3u3_0_devel_CONTENTS="
	usr/bin/wx-config-3.0
	usr/lib/libwx_gtk3u*-3.0.dll.a
	usr/lib/wx/config/gtk3-unicode-3.0
	usr/lib/wx/include/gtk3-unicode-3.0/
"
wxWidgets3_0_doc_CATEGORY="Doc"
wxWidgets3_0_doc_SUMMARY="${SUMMARY} (documentation)"
wxWidgets3_0_doc_OBSOLETES="libwx_gtk2u3.0-doc"
wxWidgets3_0_doc_CONTENTS="usr/share/doc/${NAME}/html/"

DIFF_EXCLUDES="doxygen.log out"

CFLAGS+=" -fno-strict-aliasing"
CXXFLAGS+=" -fno-strict-aliasing"

MAKEOPTS="-j13"

src_compile() {
	local myconf
	
	pushd ${S}
	NO_ACLOCAL=1 NO_LIBTOOLIZE=1 NO_AUTOHEADER=1 NO_AUTOMAKE=1 \
	cygautoreconf

	pushd ${S}/locale
	rm -f *.mo
	cygmake allmo -j1
	popd
	
	mkdir -p ${B}/base
	pushd ${B}/base

	# standalone wx_base
	cygconf \
		--enable-compat26 \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--disable-gui \
		--disable-rpath \
		--with-expat \
		--with-libiconv \
		--with-zlib

	popd
	mkdir -p ${B}/gtk2
	pushd ${B}/gtk2

	# gnomevfs: Gentoo bug 203389
	cygconf \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--enable-mediactrl \
		--disable-rpath \
		--with-expat \
		--with-gtk=2 \
		--without-gnomeprint --without-gnomevfs \
		--with-libpng \
		--with-libjpeg \
		--with-libiconv \
		--with-libmspack \
		--with-libnotify \
		--with-libtiff \
		--with-libxpm \
		--with-opengl \
		--with-sdl \
		--with-zlib

	cygmake

    popd
	mkdir -p ${B}/gtk3
	pushd ${B}/gtk3

	# gnomevfs: Gentoo bug 203389
	cygconf \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--enable-mediactrl \
		--disable-rpath \
		--with-expat \
		--with-gtk=3 \
		--without-gnomeprint --without-gnomevfs \
		--with-libpng \
		--with-libjpeg \
		--with-libiconv \
		--with-libmspack \
		--with-libnotify \
		--with-libtiff \
		--with-libxpm \
		--with-opengl \
		--with-sdl \
		--with-zlib

	cygmake

	popd
	pushd ${S}/docs/doxygen
	WX_SKIP_DOXYGEN_VERSION_CHECK=1 ./regen.sh html
	popd
}

src_test() {
	echo "--- GTK2 tests ---"
	pushd ${B}/gtk2/tests
	cygmake
	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test
	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test_gui
	popd
	
	echo "--- GTK3 tests ---"
	pushd ${B}/gtk3/tests
	cygmake
	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test
	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test_gui
	popd
}

src_install() {
	dodir /usr/lib
	cd ${B}/base
	cp -fr lib/wx/ ${D}/usr/lib/
	cd ${B}/gtk2
	cyginstall -j1
	cp -fr lib/lib*.dll.a lib/wx/ ${D}/usr/lib/
	cd ${B}/gtk3
	cyginstall -j1
	cp -fr lib/lib*.dll.a lib/wx/ ${D}/usr/lib/

	rm -f ${D}/usr/lib/wx/config/inplace-*

	mv ${D}/usr/lib/*.dll ${D}/usr/bin
	mv ${D}/usr/bin/wxrc-${slot}{,.exe}

	rm -f ${D}/usr/bin/wx-config-${slot}
	dosym ../lib/wx/config/gtk3-unicode-${slot} /usr/bin/wx-config-${slot}

	insinto /usr/share/aclocal
	newins ${S}/wxwin.m4 wxwin-${slot}.m4

	cd ${S}/docs
	dodoc changes.txt gpl.txt lgpl.txt licendoc.txt preamble.txt todo.txt

	cp -r ${S}/docs/doxygen/out/html/ ${D}/usr/share/doc/${NAME}/

	rm -f ${D}/usr/share/locale/*/LC_MESSAGES/wxmsw*.mo
}

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

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

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 12/11/2020 18:00, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 11/11/2020 17:36, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> Ignore my previous message - whatever was wrong is now fixed. I didn't
>> change anything much so I think it was a dependency that had an issue
>> and was since recompiled.
>>
>> 64-bit build is done and seems to work fine. I'm testing it using the
>> samples, nearly all of which work, and new things that weren't in the
>> previous wxwidgets build now work (eg webview with webkit).
>>
>> I need to finish my testing and then build for 32-bit Cygwin, but all
>> seems good.
>>
>> When it's all done I'll email again with my cygport file attached and a
>> link to the file locations.
>>
>> Hamish
> Okay, I have successfully manually tested wxWidgets3.0 on both 32-bit
> and 64-bit Cygwin, and I haven't found any significant issues. It also
> seems to work with my existing wxPython build but I'm going to recompile
> that anyway just to be sure and to get the new version number for
> wxWidgets in the build.
>
> The test packages are available for download at
> https://www.hamishmb.com/files/cygwin-temp/ as usual, and my cygport
> file is attached here.
>
> Here's a quick summary of the changes I've made:
>
> - Updated to wxWidgets 3.0.5.1 from 3.0.4.
>
> - Added build dependencies.
>
> - Evaluated lots of new patches (over 80), and found that nearly none of
> them were needed (already patched in new source), so we only have a few
> new patches.
>
> - Updated the wxGTK collision patch for wxwidgets 3.0.5.1 as the old one
> wouldn't apply.
>
> - Use pushd and popd instead of cd in the cygport file.
>
> - Enable automated unit tests in the cygport file (these currently do
> work so I tested manually).
>
> - Enable and test wxwebview with webkit (works fine in all configurations).
>
> I'd like to use the AppVeyor CI tool to double check the build and build
> dependencies, but the very high RAM usage during compilation (12GB!)
> makes me think it might crash that system. Is it safe for me to proceed?
> I really don't want to ruin someone's day by crashing the CI system(s).
> I think I need a GTG before  can do this because I don't currently own
> the package, but I'm not sure.
>
> Finally, I'm going to keep these as test packages until I've got
> wxPython build and tested against them, which will be maybe another week
> or so depending on other priorities.
>
> Any feedback is very welcome :)
>
> Hamish

*bump* in case this went unnoticed.

I know it's a pain checking these over because it takes so long to build
them, but I would still very much appreciate it. I am already a
maintainer for other packages, but AFAIK this doesn't give me the right
to GTG myself.

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: [ITA] wxWidgets3.0

[Brian Inglis]

On 2020-11-21 09:52, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 12/11/2020 18:00, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 11/11/2020 17:36, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> Ignore my previous message - whatever was wrong is now fixed. I didn't
>>> change anything much so I think it was a dependency that had an issue
>>> and was since recompiled.
>>>
>>> 64-bit build is done and seems to work fine. I'm testing it using the
>>> samples, nearly all of which work, and new things that weren't in the
>>> previous wxwidgets build now work (eg webview with webkit).
>>>
>>> I need to finish my testing and then build for 32-bit Cygwin, but all
>>> seems good.
>>>
>>> When it's all done I'll email again with my cygport file attached and a
>>> link to the file locations.
>>>
>>> Hamish
>> Okay, I have successfully manually tested wxWidgets3.0 on both 32-bit
>> and 64-bit Cygwin, and I haven't found any significant issues. It also
>> seems to work with my existing wxPython build but I'm going to recompile
>> that anyway just to be sure and to get the new version number for
>> wxWidgets in the build.
>>
>> The test packages are available for download at
>> https://www.hamishmb.com/files/cygwin-temp/ as usual, and my cygport
>> file is attached here.
>>
>> Here's a quick summary of the changes I've made:
>>
>> - Updated to wxWidgets 3.0.5.1 from 3.0.4.
>>
>> - Added build dependencies.
>>
>> - Evaluated lots of new patches (over 80), and found that nearly none of
>> them were needed (already patched in new source), so we only have a few
>> new patches.
>>
>> - Updated the wxGTK collision patch for wxwidgets 3.0.5.1 as the old one
>> wouldn't apply.
>>
>> - Use pushd and popd instead of cd in the cygport file.
>>
>> - Enable automated unit tests in the cygport file (these currently do
>> work so I tested manually).
>>
>> - Enable and test wxwebview with webkit (works fine in all configurations).
>>
>> I'd like to use the AppVeyor CI tool to double check the build and build
>> dependencies, but the very high RAM usage during compilation (12GB!)
>> makes me think it might crash that system. Is it safe for me to proceed?
>> I really don't want to ruin someone's day by crashing the CI system(s).
>> I think I need a GTG before  can do this because I don't currently own
>> the package, but I'm not sure.
>>
>> Finally, I'm going to keep these as test packages until I've got
>> wxPython build and tested against them, which will be maybe another week
>> or so depending on other priorities.
>>
>> Any feedback is very welcome :)
>>
>> Hamish
> 
> *bump* in case this went unnoticed.
> 
> I know it's a pain checking these over because it takes so long to build
> them, but I would still very much appreciate it. I am already a
> maintainer for other packages, but AFAIK this doesn't give me the right
> to GTG myself.

Push your cygport to the git-cygwin-packages playground repo (see Jon Turney's 
recent reply to me in this list) which all maintainers can push to, as you don't 
yet own the git-cygwin-packages wxWidgets repo; check the CI jobs.cgi log 
contents, and fix any issues.

-- 
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 binary units and prefixes, physical quantities in SI.]

Re: [ITA] wxWidgets3.0

[Achim Gratz]

Brian Inglis writes:
> Push your cygport to the git-cygwin-packages playground repo (see Jon
> Turney's recent reply to me in this list) which all maintainers can
> push to, as you don't yet own the git-cygwin-packages wxWidgets repo;
> check the CI jobs.cgi log contents, and fix any issues.

Fun fact: that will certainly run into the build timeout that is
currently set at 1 hour.  Jon, do you think it'd be possible to have
another SCALLYWAG variable to extend that limit for the packages that
need it?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 22/11/2020 09:43, Achim Gratz wrote:
> Brian Inglis writes:
>> Push your cygport to the git-cygwin-packages playground repo (see Jon
>> Turney's recent reply to me in this list) which all maintainers can
>> push to, as you don't yet own the git-cygwin-packages wxWidgets repo;
>> check the CI jobs.cgi log contents, and fix any issues.
> Fun fact: that will certainly run into the build timeout that is
> currently set at 1 hour.  Jon, do you think it'd be possible to have
> another SCALLYWAG variable to extend that limit for the packages that
> need it?
>
>
> Regards,
> Achim.

I can confirm now that I've got all the build requirements correct, that
it does indeed timeout.

Since this message (November 2020), is there now support for adjusting
the timeout for individual packages?

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: [ITA] wxWidgets3.0

[Achim Gratz]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Since this message (November 2020), is there now support for adjusting
> the timeout for individual packages?

From the AppVeyor FAQ:  You can only do that on a paid-for project, so
no unless they'd make an exception for Cygwin.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [ITA] wxWidgets3.0

[Achim Gratz]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> *bump* in case this went unnoticed.

It didn't, I just know that this GNOME crap will always need another 40
packages installed before I can even start looking.

> I know it's a pain checking these over because it takes so long to build
> them, but I would still very much appreciate it. I am already a
> maintainer for other packages, but AFAIK this doesn't give me the right
> to GTG myself.

Here's what I have so far:

1. Do not add the runtime packages to BUILD_REQUIRES (i.e if you have
zlib-devel, then don't add zlib).  If there are runtime packages you
need for testing, list them on a separate line and comment that these
are needed for testing only (xclock, graphviz?).  Currently we assume
the dependencies needed by cygport to be available always without
explicitly mentioining them (e.g. autoconf), although it doesn't hurt to
have them in.

2. The option --without-gnomeprint seems no longer available and would
be default anyway since gtkprint gets detected and used.

3. You should explicitly specify that you want to use the system regex
library, so add --with-regex=sys.

4. It should be possible to enable full STL now, so add --enable-stl.

5. If you copy the config.cache forward to the next run of configure you
can save a bit of time not rechecking stuff you already checked.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 22/11/2020 09:41, Achim Gratz wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> *bump* in case this went unnoticed.
> It didn't, I just know that this GNOME crap will always need another 40
> packages installed before I can even start looking.
>
>> I know it's a pain checking these over because it takes so long to build
>> them, but I would still very much appreciate it. I am already a
>> maintainer for other packages, but AFAIK this doesn't give me the right
>> to GTG myself.
> Here's what I have so far:
>
> 1. Do not add the runtime packages to BUILD_REQUIRES (i.e if you have
> zlib-devel, then don't add zlib).  If there are runtime packages you
> need for testing, list them on a separate line and comment that these
> are needed for testing only (xclock, graphviz?).  Currently we assume
> the dependencies needed by cygport to be available always without
> explicitly mentioining them (e.g. autoconf), although it doesn't hurt to
> have them in.
>
> 2. The option --without-gnomeprint seems no longer available and would
> be default anyway since gtkprint gets detected and used.
>
> 3. You should explicitly specify that you want to use the system regex
> library, so add --with-regex=sys.
>
> 4. It should be possible to enable full STL now, so add --enable-stl.
>
> 5. If you copy the config.cache forward to the next run of configure you
> can save a bit of time not rechecking stuff you already checked.
>
>
>
> Regards,
> Achim.

Thanks, changes made and rebuilding now.

1. I have separated these onto another line. I've kept this enabled for
manual testing, and also because other things in my Cygwin install need
some of these dependencies - I can't easily remove to be 1000% sure that
none of them are needed during building. It seems wxWidgets hasn't
documented optional build dependencies very clearly.

2. Good point, I have removed this.

3. As above, I have added this.

4. Okay, trying that in this build. Not sure how to test that any
features need that are working, so I'll have to research that.

Extra: I'm also trying to build with gnomevfs now, seeing as that Gentoo
bug is very old, and I suspect the issue has since been fixed. Will have
to figure out how to test this as well, but it looks like many things
will outright crash if this problem occurs.

I'll wait on the CI system then, this takes hours to build even on my
Ryzen 3600, especially on 32-bit Cygwin.

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: [ITA] wxWidgets3.0

[ASSI]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> 1. I have separated these onto another line. I've kept this enabled for
> manual testing, and also because other things in my Cygwin install need
> some of these dependencies - I can't easily remove to be 1000% sure that
> none of them are needed during building. It seems wxWidgets hasn't
> documented optional build dependencies very clearly.

Graphviz is actually needed for building the docs I've found.

> 4. Okay, trying that in this build. Not sure how to test that any
> features need that are working, so I'll have to research that.

Specifically, copying the config.cache from base to both of the gtk{2,3}
builds should work, but not gtk2->3.  I've re-arranged the cygport file
to first configure all three (makes it easier to hunt for differences),
then build in reverse order.

> I'll wait on the CI system then, this takes hours to build even on my
> Ryzen 3600, especially on 32-bit Cygwin.

That's odd.  I've built on a 4-core/8-thread Haswell in well under two
hours per architecture and I haven't seen memory peak above 8GiB.  You
said you are building in a VM, perhaps you should reduce the number of
threads there a bit.  If the VM starts contending for host resources
things _will_ get ugly.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 23/11/2020 15:26, ASSI wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> 1. I have separated these onto another line. I've kept this enabled for
>> manual testing, and also because other things in my Cygwin install need
>> some of these dependencies - I can't easily remove to be 1000% sure that
>> none of them are needed during building. It seems wxWidgets hasn't
>> documented optional build dependencies very clearly.
> Graphviz is actually needed for building the docs I've found.
Oh yeah, you're right. I forgot that was what it was for.
>
>> 4. Okay, trying that in this build. Not sure how to test that any
>> features need that are working, so I'll have to research that.
> Specifically, copying the config.cache from base to both of the gtk{2,3}
> builds should work, but not gtk2->3.  I've re-arranged the cygport file
> to first configure all three (makes it easier to hunt for differences),
> then build in reverse order.
Yeah, maybe I should do that as well, but I've just started another
build. Re-enabling gnomevfs did NOT work for me - causes segfaults and
wxpython can import the libraries with a "No such process" error after
doing that. Rebuilding now. I guess it could be due to using STL as
well, but we'll see.
>
>> I'll wait on the CI system then, this takes hours to build even on my
>> Ryzen 3600, especially on 32-bit Cygwin.
> That's odd.  I've built on a 4-core/8-thread Haswell in well under two
> hours per architecture and I haven't seen memory peak above 8GiB.  You
> said you are building in a VM, perhaps you should reduce the number of
> threads there a bit.  If the VM starts contending for host resources
> things _will_ get ugly.

That is strange if it's so much faster on your system. Fortunately I
have loads of memory so it's not too much of an issue for me. Most of
the time on 32-bit Cygwin is spent stripping the executables, which is
_way_ slower than on 64-bit Cygwin, by a factor of probably 3-4. Time to
rebuild again anyway. What fun...

Thanks Achim,

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: [ITA] wxWidgets3.0

[ASSI]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> That is strange if it's so much faster on your system.

I've checked again to be sure:

Compile 41 minutes, install 7 (32bit) / 4 (64bit) minutes, packaging 5
minutes.

> Fortunately I have loads of memory so it's not too much of an issue
> for me. Most of the time on 32-bit Cygwin is spent stripping the
> executables, which is _way_ slower than on 64-bit Cygwin, by a factor
> of probably 3-4.

What's the disk based on?  I've recently switched to NVMe and while it's
not doing wonders compared to the SATA-SSD I've had before it has helped
to shave some time off the builds, generally in the order of 10…25% (for
gcc that means about half an hour so that's very welcome even if it
doesn't sound much).  Running a VM probably means you're running on a
filesystem image rather than a dedicated disk and that probably means an
extra slowdown anyway.  NVMe would enable you to make that overhead go
away, but it needs to be supported through the whole hypervisor / VM
stack to be effective.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 23/11/2020 19:16, ASSI wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> That is strange if it's so much faster on your system.
> I've checked again to be sure:
>
> Compile 41 minutes, install 7 (32bit) / 4 (64bit) minutes, packaging 5
> minutes.

Okay, wow that is a LOT quicker. I haven't timed mine precisely buts
it's something like:

Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit),
packaging probably like 5 minutes.

>> Fortunately I have loads of memory so it's not too much of an issue
>> for me. Most of the time on 32-bit Cygwin is spent stripping the
>> executables, which is _way_ slower than on 64-bit Cygwin, by a factor
>> of probably 3-4.
> What's the disk based on?  I've recently switched to NVMe and while it's
> not doing wonders compared to the SATA-SSD I've had before it has helped
> to shave some time off the builds, generally in the order of 10…25% (for
> gcc that means about half an hour so that's very welcome even if it
> doesn't sound much).  Running a VM probably means you're running on a
> filesystem image rather than a dedicated disk and that probably means an
> extra slowdown anyway.  NVMe would enable you to make that overhead go
> away, but it needs to be supported through the whole hypervisor / VM
> stack to be effective.

I have an NVME disk, but all my VMs (including this one) are on a SATA
disk, and it's a Samsung QVO 1TB one that was cheaper but also slower
(sustained write slows down to 80 MB/s eventually). Read is quick
though. IIRC it's presented as SATA to the VM too.

I'd better have a look at my configuration. Maybe do some disk and CPU
benchmarks. This is in virtualbox so perhaps it's yet another problem
with that, in the long list of problems I seem to have with virtualbox.
The VM has 16GB of RAM dedicated to it, how does that compare to your
system?

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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 23/11/2020 19:24, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 23/11/2020 19:16, ASSI wrote:
>> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>>> That is strange if it's so much faster on your system.
>> I've checked again to be sure:
>>
>> Compile 41 minutes, install 7 (32bit) / 4 (64bit) minutes, packaging 5
>> minutes.
> Okay, wow that is a LOT quicker. I haven't timed mine precisely buts
> it's something like:
>
> Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit),
> packaging probably like 5 minutes.
>
>>> Fortunately I have loads of memory so it's not too much of an issue
>>> for me. Most of the time on 32-bit Cygwin is spent stripping the
>>> executables, which is _way_ slower than on 64-bit Cygwin, by a factor
>>> of probably 3-4.
>> What's the disk based on?  I've recently switched to NVMe and while it's
>> not doing wonders compared to the SATA-SSD I've had before it has helped
>> to shave some time off the builds, generally in the order of 10…25% (for
>> gcc that means about half an hour so that's very welcome even if it
>> doesn't sound much).  Running a VM probably means you're running on a
>> filesystem image rather than a dedicated disk and that probably means an
>> extra slowdown anyway.  NVMe would enable you to make that overhead go
>> away, but it needs to be supported through the whole hypervisor / VM
>> stack to be effective.
> I have an NVME disk, but all my VMs (including this one) are on a SATA
> disk, and it's a Samsung QVO 1TB one that was cheaper but also slower
> (sustained write slows down to 80 MB/s eventually). Read is quick
> though. IIRC it's presented as SATA to the VM too.
>
> I'd better have a look at my configuration. Maybe do some disk and CPU
> benchmarks. This is in virtualbox so perhaps it's yet another problem
> with that, in the long list of problems I seem to have with virtualbox.
> The VM has 16GB of RAM dedicated to it, how does that compare to your
> system?
>
> Hamish

I think my fork speed is quite slow - when it prints out the "wxwidgets
has been installed, update LD_LIBRARY_PATH yada yada" messages during
install I can see it printing out the individual lines.

I don't know whether it was always that slow.

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: [ITA] wxWidgets3.0

[ASSI]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Okay, wow that is a LOT quicker. I haven't timed mine precisely buts
> it's something like:

Just look at the files in the log/ folder.

> Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit),
> packaging probably like 5 minutes.

Ouch.

> I have an NVME disk, but all my VMs (including this one) are on a SATA
> disk, and it's a Samsung QVO 1TB one that was cheaper but also slower
> (sustained write slows down to 80 MB/s eventually). Read is quick
> though. IIRC it's presented as SATA to the VM too.

What you really need to look for is IOPS/latency, not bandwidth.  I
rarely see upwards of 60MByte/s through NTFS unless very large files are
involved (and only then I've ever seen it surpass the SATA barrier of
~550MByte/s and not by much), but the QVO is better suited for warm
storage / backups and has pretty long response times and the low IOPS
that come with it when you fill the queue.  The NVMe on the other hand
mostly registers below 1ms where the former SATA disk (a WD Blue) was
all over the map up to almost 300ms at times and around 3…10ms average
under load.

> I'd better have a look at my configuration. Maybe do some disk and CPU
> benchmarks. This is in virtualbox so perhaps it's yet another problem
> with that, in the long list of problems I seem to have with virtualbox.
> The VM has 16GB of RAM dedicated to it, how does that compare to your
> system?

That system is at its official max. configuration of 32GiB (4x8GiB ECC).
But as I said, it was running around 6GiB for the whole build with some
brief spikes to maybe 8GiB.  So that seems unlikely to be your problem.

You run your VM (virtual storage controller) in AHCI mode or not?  That
should be the standard option for a recent Windows VM, but if not, then
rather abysmal disk performance is semi-expected.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 23/11/2020 20:05, ASSI wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> Okay, wow that is a LOT quicker. I haven't timed mine precisely buts
>> it's something like:
> Just look at the files in the log/ folder.
Okay, shall do once this build is done.
>
>> Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit),
>> packaging probably like 5 minutes.
> Ouch.
>
>> I have an NVME disk, but all my VMs (including this one) are on a SATA
>> disk, and it's a Samsung QVO 1TB one that was cheaper but also slower
>> (sustained write slows down to 80 MB/s eventually). Read is quick
>> though. IIRC it's presented as SATA to the VM too.
> What you really need to look for is IOPS/latency, not bandwidth.  I
> rarely see upwards of 60MByte/s through NTFS unless very large files are
> involved (and only then I've ever seen it surpass the SATA barrier of
> ~550MByte/s and not by much), but the QVO is better suited for warm
> storage / backups and has pretty long response times and the low IOPS
> that come with it when you fill the queue.  The NVMe on the other hand
> mostly registers below 1ms where the former SATA disk (a WD Blue) was
> all over the map up to almost 300ms at times and around 3…10ms average
> under load.
I did a test with CrystalDiskMark and my speeds for sustained read and
write were 2+ GB/s, and 4k and random were 100MB/s and 40MB/s, so I
think that should be good enough. I think the GB/s figures come from
using the I/O cache (host is Linux), so it's just reading and writing
straight from/to RAM. The system itself has 32GB of RAM as well.
>> I'd better have a look at my configuration. Maybe do some disk and CPU
>> benchmarks. This is in virtualbox so perhaps it's yet another problem
>> with that, in the long list of problems I seem to have with virtualbox.
>> The VM has 16GB of RAM dedicated to it, how does that compare to your
>> system?
> That system is at its official max. configuration of 32GiB (4x8GiB ECC).
> But as I said, it was running around 6GiB for the whole build with some
> brief spikes to maybe 8GiB.  So that seems unlikely to be your problem.
>
> You run your VM (virtual storage controller) in AHCI mode or not?  That
> should be the standard option for a recent Windows VM, but if not, then
> rather abysmal disk performance is semi-expected.

Yeah, it's AHCI.

I've tried turning Avira Antivirus off for the next rebuild (segfault
and wxpython issues may be have been due to STL, not gnomevfs). I
already had exceptions for C:\cygwin64 and C:\cygwin, but we'll see if
that makes it any quicker. I guess I'll keep digging in the meantime.
Perhaps Cygwin and VirtualBox just don't work well together. I'm not
sure if it used to be faster.

Thanks for all the 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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

Well, something's gone wrong with my Cygwin install I think, because
even with previously working cygport recipes, I can no longer produce a
working build.

The samples tend to either exit immediately or segfault, and trying to
use wxPython yields:

"

Traceback (most recent call last):

  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main

    "__main__", mod_spec)

  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code

    exec(code, run_globals)

  File "./demo/__main__.py", line 5, in <module>

    import Main

  File "./demo/Main.py", line 61, in <module>

    import wx

  File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in
<module>

    from wx.core import *

  File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in <module>

    from ._core import *

ImportError: No such process


"

I did try a rebase as well, but it doesn't seem to help. This looks like
an issue I had right when I first tried to compile wxPython, and it
mysteriously went away at some point. Does anyone know why this might be
happening? Maybe I need to reinstall Cygwin, but I haven't done anything
with it between the successful build of wxWidgets and the failed ones,
so it's not making a whole lot of sense.

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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

Ignore that message, I made a silly mistake.

On 24/11/2020 10:15, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Well, something's gone wrong with my Cygwin install I think, because
> even with previously working cygport recipes, I can no longer produce a
> working build.
>
> The samples tend to either exit immediately or segfault, and trying to
> use wxPython yields:
>
> "
>
> Traceback (most recent call last):
>
>   File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
>
>     "__main__", mod_spec)
>
>   File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
>
>     exec(code, run_globals)
>
>   File "./demo/__main__.py", line 5, in <module>
>
>     import Main
>
>   File "./demo/Main.py", line 61, in <module>
>
>     import wx
>
>   File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in
> <module>
>
>     from wx.core import *
>
>   File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in <module>
>
>     from ._core import *
>
> ImportError: No such process
>
>
> "
>
> I did try a rebase as well, but it doesn't seem to help. This looks like
> an issue I had right when I first tried to compile wxPython, and it
> mysteriously went away at some point. Does anyone know why this might be
> happening? Maybe I need to reinstall Cygwin, but I haven't done anything
> with it between the successful build of wxWidgets and the failed ones,
> so it's not making a whole lot of sense.
>
> 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: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 24/11/2020 10:43, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Ignore that message, I made a silly mistake.
>
> On 24/11/2020 10:15, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> Well, something's gone wrong with my Cygwin install I think, because
>> even with previously working cygport recipes, I can no longer produce a
>> working build.
>>
>> The samples tend to either exit immediately or segfault, and trying to
>> use wxPython yields:
>>
>> "
>>
>> Traceback (most recent call last):
>>
>>   File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
>>
>>     "__main__", mod_spec)
>>
>>   File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
>>
>>     exec(code, run_globals)
>>
>>   File "./demo/__main__.py", line 5, in <module>
>>
>>     import Main
>>
>>   File "./demo/Main.py", line 61, in <module>
>>
>>     import wx
>>
>>   File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in
>> <module>
>>
>>     from wx.core import *
>>
>>   File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in <module>
>>
>>     from ._core import *
>>
>> ImportError: No such process
>>
>>
>> "
>>
>> I did try a rebase as well, but it doesn't seem to help. This looks like
>> an issue I had right when I first tried to compile wxPython, and it
>> mysteriously went away at some point. Does anyone know why this might be
>> happening? Maybe I need to reinstall Cygwin, but I haven't done anything
>> with it between the successful build of wxWidgets and the failed ones,
>> so it's not making a whole lot of sense.
>>
>> Hamish

Okay, so attached is my latest cygport file. I'm still building for
32-bit, so I'll upload and link to the new packages tomorrow.

Changes:

- Split BUILD_REQUIRES across two lines for definitely build time and
probably only runtime deps.

- Use system regex library explicitly.

- Removed obsolete --without-gnomeprint option.

- Use gnomevfs (old bug no longer seems to apply).

I tried using the STL, but it results in libraries that don't work as:

#1: the wxwidgets demos either segfault instantly or just exit instantly.

#2: wxpython no longer works and returns the No such process error above.

Hamish


[-- Attachment #1.1.2: wxWidgets3.0.cygport --]
[-- Type: text/plain, Size: 6626 bytes --]

NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/"
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2"
SRC_DIR="wxWidgets-${VERSION}"

#Just for building:
BUILD_REQUIRES="make cppunit graphviz autoconf pkg-config gcc-core gcc-g++ doxygen libX11-devel libgtk2.0-devel libgtk3-devel libwebkitgtk1.0-devel libwebkitgtk3.0-devel libpng-devel libjpeg-devel libexpat-devel libiconv-devel libmspack-devel libnotify-devel libtiff-devel libXpm-devel libcogl-devel libEGL-devel libGL-devel libGLU-devel libSDL2-devel libSDL2_image-devel libSDL2_mixer-devel libSDL2_net-devel libSDL2_ttf-devel zlib-devel"

#For running unit tests/runtime (currently disabled because they don't work).
#Still needed for manual testing though, so leaving in here.
BUILD_REQUIRES="$BUILD_REQUIRES xclock libwebkitgtk1.0_0 libwebkitgtk3.0_0 libpng16 libjpeg8 libexpat1 libiconv libiconv2 libmspack0 libnotify libnotify4 libtiff6 libXpm4 libcogl20 libEGL1 libGL1 libGLU1 libSDL2_2.0_0 libSDL2_image2.0_0 libSDL2_mixer2.0_0 libSDL2_net2.0_0 libSDL2_ttf2.0_0 zlib"

PATCH_URI="
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
	wxGTK3-3.0.5.1-collision.patch
	3.0.2-cygwin-auto-import.patch
	3.0.2-cygwin-dlopen.patch
	3.0.2-cygwin-unix.patch
	3.0.2-cygwin-gcc5.patch
	3.0.3-autoreconf.patch
	3.0.3-cygwin-ftm.patch
	0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"

slot=${PV_MAJ_MIN}

PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
           libwx_gtk2u3.0_0 libwx_gtk2u3.0-devel
           libwx_gtk3u3.0_0 libwx_gtk3u3.0-devel"
libwx_baseu3_0_0_SUMMARY="${SUMMARY} (base unicode runtime)"
libwx_baseu3_0_0_CONTENTS="
	--exclude=html
	usr/bin/cygwx_baseu*-3.0-0.dll
	usr/share/doc/${NAME}/
	usr/share/locale/*/LC_MESSAGES/wxstd30.mo
"
libwx_baseu3_0_devel_REQUIRES="libexpat-devel libiconv-devel zlib-devel"
libwx_baseu3_0_devel_CONTENTS="
	usr/bin/wxrc-3.0.exe
	usr/include/wx-3.0/
	usr/lib/libwx_baseu*-3.0.dll.a
	usr/lib/wx/config/base-unicode-3.0
	usr/lib/wx/include/base-unicode-3.0/
	usr/share/aclocal/wxwin-3.0.m4
	usr/share/bakefile/presets/wx30*
"
libwx_gtk2u3_0_0_SUMMARY="${SUMMARY} (GTK+2 unicode runtime)"
libwx_gtk2u3_0_0_CONTENTS="usr/bin/cygwx_gtk2u*-3.0-0.dll"
libwx_gtk2u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk2u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel libX11-devel"
libwx_gtk2u3_0_devel_CONTENTS="
	usr/lib/libwx_gtk2u*-3.0.dll.a
	usr/lib/wx/config/gtk2-unicode-3.0
	usr/lib/wx/include/gtk2-unicode-3.0/
"
libwx_gtk3u3_0_0_SUMMARY="${SUMMARY} (GTK+3 unicode runtime)"
libwx_gtk3u3_0_0_CONTENTS="usr/bin/cygwx_gtk3u*-3.0-0.dll"
libwx_gtk3u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk3u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel libX11-devel"
libwx_gtk3u3_0_devel_CONTENTS="
	usr/bin/wx-config-3.0
	usr/lib/libwx_gtk3u*-3.0.dll.a
	usr/lib/wx/config/gtk3-unicode-3.0
	usr/lib/wx/include/gtk3-unicode-3.0/
"
wxWidgets3_0_doc_CATEGORY="Doc"
wxWidgets3_0_doc_SUMMARY="${SUMMARY} (documentation)"
wxWidgets3_0_doc_OBSOLETES="libwx_gtk2u3.0-doc"
wxWidgets3_0_doc_CONTENTS="usr/share/doc/${NAME}/html/"

DIFF_EXCLUDES="doxygen.log out"

CFLAGS+=" -fno-strict-aliasing"
CXXFLAGS+=" -fno-strict-aliasing"

MAKEOPTS="-j13"

src_compile() {
	#NB: gnomevfs is disabled due to Gentoo bug 203389: https://bugs.gentoo.org/203389
	#which causes a segfault.
	local myconf
	
	pushd ${S}
	NO_ACLOCAL=1 NO_LIBTOOLIZE=1 NO_AUTOHEADER=1 NO_AUTOMAKE=1 \
	cygautoreconf

	pushd ${S}/locale
	rm -f *.mo
	cygmake allmo -j1
	popd
	
	mkdir -p ${B}/base
	pushd ${B}/base

	# standalone wx_base
	cygconf \
		--enable-compat26 \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--disable-gui \
		--disable-rpath \
		--with-regex=sys \
		--with-expat \
		--with-libiconv \
		--with-zlib

	popd
	mkdir -p ${B}/gtk2
	pushd ${B}/gtk2

	cygconf \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--enable-mediactrl \
		--disable-rpath \
		--with-regex=sys \
		--with-expat \
		--with-gtk=2 \
		--with-libpng \
		--with-libjpeg \
		--with-libiconv \
		--with-libmspack \
		--with-libnotify \
		--with-libtiff \
		--with-libxpm \
		--with-opengl \
		--with-sdl \
		--with-zlib

	cygmake

    popd
	mkdir -p ${B}/gtk3
	pushd ${B}/gtk3

	cygconf \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--enable-mediactrl \
		--disable-rpath \
		--with-regex=sys \
		--with-expat \
		--with-gtk=3 \
		--with-libpng \
		--with-libjpeg \
		--with-libiconv \
		--with-libmspack \
		--with-libnotify \
		--with-libtiff \
		--with-libxpm \
		--with-opengl \
		--with-sdl \
		--with-zlib

	cygmake

	popd
	pushd ${S}/docs/doxygen
	WX_SKIP_DOXYGEN_VERSION_CHECK=1 ./regen.sh html
	popd
}

#Disabled, as automated tests are currently not working.
#src_test() {
#	echo "--- GTK2 tests ---"
#	pushd ${B}/gtk2/tests
#	cygmake
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test_gui
#	popd
#	
#	echo "--- GTK3 tests ---"
#	pushd ${B}/gtk3/tests
#	cygmake
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test_gui
#	popd
#}

src_install() {
	dodir /usr/lib
	cd ${B}/base
	cp -fr lib/wx/ ${D}/usr/lib/
	cd ${B}/gtk2
	cyginstall -j1
	cp -fr lib/lib*.dll.a lib/wx/ ${D}/usr/lib/
	cd ${B}/gtk3
	cyginstall -j1
	cp -fr lib/lib*.dll.a lib/wx/ ${D}/usr/lib/

	rm -f ${D}/usr/lib/wx/config/inplace-*

	mv ${D}/usr/lib/*.dll ${D}/usr/bin
	mv ${D}/usr/bin/wxrc-${slot}{,.exe}

	rm -f ${D}/usr/bin/wx-config-${slot}
	dosym ../lib/wx/config/gtk3-unicode-${slot} /usr/bin/wx-config-${slot}

	insinto /usr/share/aclocal
	newins ${S}/wxwin.m4 wxwin-${slot}.m4

	cd ${S}/docs
	dodoc changes.txt gpl.txt lgpl.txt licendoc.txt preamble.txt todo.txt

	cp -r ${S}/docs/doxygen/out/html/ ${D}/usr/share/doc/${NAME}/

	rm -f ${D}/usr/share/locale/*/LC_MESSAGES/wxmsw*.mo
}

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

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

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

> Okay, so attached is my latest cygport file. I'm still building for
> 32-bit, so I'll upload and link to the new packages tomorrow.
>
> Changes:
>
> - Split BUILD_REQUIRES across two lines for definitely build time and
> probably only runtime deps.
>
> - Use system regex library explicitly.
>
> - Removed obsolete --without-gnomeprint option.
>
> - Use gnomevfs (old bug no longer seems to apply).
>
> I tried using the STL, but it results in libraries that don't work as:
>
> #1: the wxwidgets demos either segfault instantly or just exit instantly.
>
> #2: wxpython no longer works and returns the No such process error above.
>
> Hamish

Okay, cygport file attached again and the new packages can be had from
https://www.hamishmb.com/files/cygwin-temp/ as before.

Hamish


[-- Attachment #1.1.2: wxWidgets3.0.cygport --]
[-- Type: text/plain, Size: 6626 bytes --]

NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/"
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2"
SRC_DIR="wxWidgets-${VERSION}"

#Just for building:
BUILD_REQUIRES="make cppunit graphviz autoconf pkg-config gcc-core gcc-g++ doxygen libX11-devel libgtk2.0-devel libgtk3-devel libwebkitgtk1.0-devel libwebkitgtk3.0-devel libpng-devel libjpeg-devel libexpat-devel libiconv-devel libmspack-devel libnotify-devel libtiff-devel libXpm-devel libcogl-devel libEGL-devel libGL-devel libGLU-devel libSDL2-devel libSDL2_image-devel libSDL2_mixer-devel libSDL2_net-devel libSDL2_ttf-devel zlib-devel"

#For running unit tests/runtime (currently disabled because they don't work).
#Still needed for manual testing though, so leaving in here.
BUILD_REQUIRES="$BUILD_REQUIRES xclock libwebkitgtk1.0_0 libwebkitgtk3.0_0 libpng16 libjpeg8 libexpat1 libiconv libiconv2 libmspack0 libnotify libnotify4 libtiff6 libXpm4 libcogl20 libEGL1 libGL1 libGLU1 libSDL2_2.0_0 libSDL2_image2.0_0 libSDL2_mixer2.0_0 libSDL2_net2.0_0 libSDL2_ttf2.0_0 zlib"

PATCH_URI="
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
	https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
	wxGTK3-3.0.5.1-collision.patch
	3.0.2-cygwin-auto-import.patch
	3.0.2-cygwin-dlopen.patch
	3.0.2-cygwin-unix.patch
	3.0.2-cygwin-gcc5.patch
	3.0.3-autoreconf.patch
	3.0.3-cygwin-ftm.patch
	0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"

slot=${PV_MAJ_MIN}

PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
           libwx_gtk2u3.0_0 libwx_gtk2u3.0-devel
           libwx_gtk3u3.0_0 libwx_gtk3u3.0-devel"
libwx_baseu3_0_0_SUMMARY="${SUMMARY} (base unicode runtime)"
libwx_baseu3_0_0_CONTENTS="
	--exclude=html
	usr/bin/cygwx_baseu*-3.0-0.dll
	usr/share/doc/${NAME}/
	usr/share/locale/*/LC_MESSAGES/wxstd30.mo
"
libwx_baseu3_0_devel_REQUIRES="libexpat-devel libiconv-devel zlib-devel"
libwx_baseu3_0_devel_CONTENTS="
	usr/bin/wxrc-3.0.exe
	usr/include/wx-3.0/
	usr/lib/libwx_baseu*-3.0.dll.a
	usr/lib/wx/config/base-unicode-3.0
	usr/lib/wx/include/base-unicode-3.0/
	usr/share/aclocal/wxwin-3.0.m4
	usr/share/bakefile/presets/wx30*
"
libwx_gtk2u3_0_0_SUMMARY="${SUMMARY} (GTK+2 unicode runtime)"
libwx_gtk2u3_0_0_CONTENTS="usr/bin/cygwx_gtk2u*-3.0-0.dll"
libwx_gtk2u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk2u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel libX11-devel"
libwx_gtk2u3_0_devel_CONTENTS="
	usr/lib/libwx_gtk2u*-3.0.dll.a
	usr/lib/wx/config/gtk2-unicode-3.0
	usr/lib/wx/include/gtk2-unicode-3.0/
"
libwx_gtk3u3_0_0_SUMMARY="${SUMMARY} (GTK+3 unicode runtime)"
libwx_gtk3u3_0_0_CONTENTS="usr/bin/cygwx_gtk3u*-3.0-0.dll"
libwx_gtk3u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk3u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel libX11-devel"
libwx_gtk3u3_0_devel_CONTENTS="
	usr/bin/wx-config-3.0
	usr/lib/libwx_gtk3u*-3.0.dll.a
	usr/lib/wx/config/gtk3-unicode-3.0
	usr/lib/wx/include/gtk3-unicode-3.0/
"
wxWidgets3_0_doc_CATEGORY="Doc"
wxWidgets3_0_doc_SUMMARY="${SUMMARY} (documentation)"
wxWidgets3_0_doc_OBSOLETES="libwx_gtk2u3.0-doc"
wxWidgets3_0_doc_CONTENTS="usr/share/doc/${NAME}/html/"

DIFF_EXCLUDES="doxygen.log out"

CFLAGS+=" -fno-strict-aliasing"
CXXFLAGS+=" -fno-strict-aliasing"

MAKEOPTS="-j13"

src_compile() {
	#NB: gnomevfs is disabled due to Gentoo bug 203389: https://bugs.gentoo.org/203389
	#which causes a segfault.
	local myconf
	
	pushd ${S}
	NO_ACLOCAL=1 NO_LIBTOOLIZE=1 NO_AUTOHEADER=1 NO_AUTOMAKE=1 \
	cygautoreconf

	pushd ${S}/locale
	rm -f *.mo
	cygmake allmo -j1
	popd
	
	mkdir -p ${B}/base
	pushd ${B}/base

	# standalone wx_base
	cygconf \
		--enable-compat26 \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--disable-gui \
		--disable-rpath \
		--with-regex=sys \
		--with-expat \
		--with-libiconv \
		--with-zlib

	popd
	mkdir -p ${B}/gtk2
	pushd ${B}/gtk2

	cygconf \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--enable-mediactrl \
		--disable-rpath \
		--with-regex=sys \
		--with-expat \
		--with-gtk=2 \
		--with-libpng \
		--with-libjpeg \
		--with-libiconv \
		--with-libmspack \
		--with-libnotify \
		--with-libtiff \
		--with-libxpm \
		--with-opengl \
		--with-sdl \
		--with-zlib

	cygmake

    popd
	mkdir -p ${B}/gtk3
	pushd ${B}/gtk3

	cygconf \
		--enable-optimise \
		--enable-shared \
		--enable-unicode \
		--enable-mediactrl \
		--disable-rpath \
		--with-regex=sys \
		--with-expat \
		--with-gtk=3 \
		--with-libpng \
		--with-libjpeg \
		--with-libiconv \
		--with-libmspack \
		--with-libnotify \
		--with-libtiff \
		--with-libxpm \
		--with-opengl \
		--with-sdl \
		--with-zlib

	cygmake

	popd
	pushd ${S}/docs/doxygen
	WX_SKIP_DOXYGEN_VERSION_CHECK=1 ./regen.sh html
	popd
}

#Disabled, as automated tests are currently not working.
#src_test() {
#	echo "--- GTK2 tests ---"
#	pushd ${B}/gtk2/tests
#	cygmake
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test_gui
#	popd
#	
#	echo "--- GTK3 tests ---"
#	pushd ${B}/gtk3/tests
#	cygmake
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test
#	DISPLAY=:0 PATH="${B}/lib:$PATH" ./test_gui
#	popd
#}

src_install() {
	dodir /usr/lib
	cd ${B}/base
	cp -fr lib/wx/ ${D}/usr/lib/
	cd ${B}/gtk2
	cyginstall -j1
	cp -fr lib/lib*.dll.a lib/wx/ ${D}/usr/lib/
	cd ${B}/gtk3
	cyginstall -j1
	cp -fr lib/lib*.dll.a lib/wx/ ${D}/usr/lib/

	rm -f ${D}/usr/lib/wx/config/inplace-*

	mv ${D}/usr/lib/*.dll ${D}/usr/bin
	mv ${D}/usr/bin/wxrc-${slot}{,.exe}

	rm -f ${D}/usr/bin/wx-config-${slot}
	dosym ../lib/wx/config/gtk3-unicode-${slot} /usr/bin/wx-config-${slot}

	insinto /usr/share/aclocal
	newins ${S}/wxwin.m4 wxwin-${slot}.m4

	cd ${S}/docs
	dodoc changes.txt gpl.txt lgpl.txt licendoc.txt preamble.txt todo.txt

	cp -r ${S}/docs/doxygen/out/html/ ${D}/usr/share/doc/${NAME}/

	rm -f ${D}/usr/share/locale/*/LC_MESSAGES/wxmsw*.mo
}

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

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

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> Okay, so attached is my latest cygport file. I'm still building for
>> 32-bit, so I'll upload and link to the new packages tomorrow.
>>
>> Changes:
>>
>> - Split BUILD_REQUIRES across two lines for definitely build time and
>> probably only runtime deps.
>>
>> - Use system regex library explicitly.
>>
>> - Removed obsolete --without-gnomeprint option.
>>
>> - Use gnomevfs (old bug no longer seems to apply).
>>
>> I tried using the STL, but it results in libraries that don't work as:
>>
>> #1: the wxwidgets demos either segfault instantly or just exit instantly.
>>
>> #2: wxpython no longer works and returns the No such process error above.
>>
>> Hamish
> Okay, cygport file attached again and the new packages can be had from
> https://www.hamishmb.com/files/cygwin-temp/ as before.
>
> Hamish

*bump*

Would be good to get this verified so I can get on to other things for
Cygwin.

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: [ITA] wxWidgets3.0

[Marco Atzeri]

On 09.12.2020 21:55, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> Okay, so attached is my latest cygport file. I'm still building for
>>> 32-bit, so I'll upload and link to the new packages tomorrow.
>>>
>>> Changes:
>>>
>>> - Split BUILD_REQUIRES across two lines for definitely build time and
>>> probably only runtime deps.
>>>
>>> - Use system regex library explicitly.
>>>
>>> - Removed obsolete --without-gnomeprint option.
>>>
>>> - Use gnomevfs (old bug no longer seems to apply).
>>>
>>> I tried using the STL, but it results in libraries that don't work as:
>>>
>>> #1: the wxwidgets demos either segfault instantly or just exit instantly.
>>>
>>> #2: wxpython no longer works and returns the No such process error above.
>>>
>>> Hamish
>> Okay, cygport file attached again and the new packages can be had from
>> https://www.hamishmb.com/files/cygwin-temp/ as before.
>>
>> Hamish
> 
> *bump*
> 
> Would be good to get this verified so I can get on to other things for
> Cygwin.
> 
> Hamish
> 

it builds and packages fine.

but I tried to build the tests on gtk3/tests

   make test.exe

and it fails

Regards
Marco

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 13/12/2020 20:12, Marco Atzeri via Cygwin-apps wrote:
> On 09.12.2020 21:55, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>>> Okay, so attached is my latest cygport file. I'm still building for
>>>> 32-bit, so I'll upload and link to the new packages tomorrow.
>>>>
>>>> Changes:
>>>>
>>>> - Split BUILD_REQUIRES across two lines for definitely build time and
>>>> probably only runtime deps.
>>>>
>>>> - Use system regex library explicitly.
>>>>
>>>> - Removed obsolete --without-gnomeprint option.
>>>>
>>>> - Use gnomevfs (old bug no longer seems to apply).
>>>>
>>>> I tried using the STL, but it results in libraries that don't work as:
>>>>
>>>> #1: the wxwidgets demos either segfault instantly or just exit
>>>> instantly.
>>>>
>>>> #2: wxpython no longer works and returns the No such process error
>>>> above.
>>>>
>>>> Hamish
>>> Okay, cygport file attached again and the new packages can be had from
>>> https://www.hamishmb.com/files/cygwin-temp/ as before.
>>>
>>> Hamish
>>
>> *bump*
>> Would be good to get this verified so I can get on to other things for
>> Cygwin.
>>
>> Hamish
>>
>
> it builds and packages fine.
>
> but I tried to build the tests on gtk3/tests
>
>   make test.exe
>
> and it fails
>
> Regards
> Marco

Hi Marco,

Yes, it does seem that the unit tests do not work correctly right now. I
thought I had put a note about that in the emails and/or cygport file -
my bad.

The tests compile if you remove all references to the fswatcher
component, but the results even when doing this are:

- Cmdline tests segfault after a while.

- GUI tests work, but only after installing wxWidgets tin the Cygwin
installation. Many GTK3 tests fail, but I tested equivalent
functionality manually and it seemed okay.

So instead of using the automated tests, I built the samples under
gtk2/samples and gtk3/samples and tested them manually. I've also built
a test version of wxPython against this new build of wxWidgets and used
the wxPython demo for even more manual testing. All seemed okay.

I plan to build wxWidgets 3.1.x soon, which is still being updated, so I
figure time is better spent trying to fix the unit tests for that
release, and manual tested is hopefully good enough for the moment?

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: [ITA] wxWidgets3.0

[Marco Atzeri]

On 14.12.2020 10:46, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 13/12/2020 20:12, Marco Atzeri via Cygwin-apps wrote:
>> On 09.12.2020 21:55, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

>>>
>>
>> it builds and packages fine.
>>
>> but I tried to build the tests on gtk3/tests
>>
>>    make test.exe
>>
>> and it fails
>>
>> Regards
>> Marco
> 
> Hi Marco,
> 
> Yes, it does seem that the unit tests do not work correctly right now. I
> thought I had put a note about that in the emails and/or cygport file -
> my bad.
> 
> The tests compile if you remove all references to the fswatcher
> component, but the results even when doing this are:
> 
> - Cmdline tests segfault after a while.
> 
> - GUI tests work, but only after installing wxWidgets tin the Cygwin
> installation. Many GTK3 tests fail, but I tested equivalent
> functionality manually and it seemed okay.
> 
> So instead of using the automated tests, I built the samples under
> gtk2/samples and gtk3/samples and tested them manually. I've also built
> a test version of wxPython against this new build of wxWidgets and used
> the wxPython demo for even more manual testing. All seemed okay.
> 
> I plan to build wxWidgets 3.1.x soon, which is still being updated, so I
> figure time is better spent trying to fix the unit tests for that
> release, and manual tested is hopefully good enough for the moment?
> 
> Hamish
> 

ok, thanks

changed maintainer

Re: [ITA] wxWidgets3.0

[Hamish McIntyre-Bhatty]

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

On 14/12/2020 20:21, Marco Atzeri via Cygwin-apps wrote:
> On 14.12.2020 10:46, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 13/12/2020 20:12, Marco Atzeri via Cygwin-apps wrote:
>>> On 09.12.2020 21:55, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>>> On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>
>>>>
>>>
>>> it builds and packages fine.
>>>
>>> but I tried to build the tests on gtk3/tests
>>>
>>>    make test.exe
>>>
>>> and it fails
>>>
>>> Regards
>>> Marco
>>
>> Hi Marco,
>>
>> Yes, it does seem that the unit tests do not work correctly right now. I
>> thought I had put a note about that in the emails and/or cygport file -
>> my bad.
>>
>> The tests compile if you remove all references to the fswatcher
>> component, but the results even when doing this are:
>>
>> - Cmdline tests segfault after a while.
>>
>> - GUI tests work, but only after installing wxWidgets tin the Cygwin
>> installation. Many GTK3 tests fail, but I tested equivalent
>> functionality manually and it seemed okay.
>>
>> So instead of using the automated tests, I built the samples under
>> gtk2/samples and gtk3/samples and tested them manually. I've also built
>> a test version of wxPython against this new build of wxWidgets and used
>> the wxPython demo for even more manual testing. All seemed okay.
>>
>> I plan to build wxWidgets 3.1.x soon, which is still being updated, so I
>> figure time is better spent trying to fix the unit tests for that
>> release, and manual tested is hopefully good enough for the moment?
>>
>> Hamish
>>
>
> ok, thanks
>
> changed maintainer

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