[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] Feedback Required: Windows 32-bit Wheels
From:       Kyle Altendorf <sda () fstab ! net>
Date:       2018-08-20 17:16:52
Message-ID: 126f1f01140796a5a33852d8d4c07608 () fstab ! net
[Download RAW message or body]



On 2018-08-20 12:31, Phil Thompson wrote:
> On 20 Aug 2018, at 5:23 pm, Kyle Altendorf <sda@fstab.net> wrote:
>> 
>> 
>> 
>> On 2018-08-16 10:27, Phil Thompson wrote:
>>> On 16 Aug 2018, at 3:13 pm, Kyle Altendorf <sda@fstab.net> wrote:
>>>> On August 16, 2018 7:41:17 AM EDT, Phil Thompson 
>>>> <phil@riverbankcomputing.com> wrote:
>>>>> Given that 32-bit Windows seems to be becoming a second class 
>>>>> citizen
>>>>> as far as Qt is concerned (ie. there is no 32-bit Web Engine any 
>>>>> more),
>>>>> I am considering dropping the 32-bit Windows wheels. 32-bit Windows
>>>>> would still be supported when building from source.
>>>> I use 32-bit windows wheels because of automated tests I have for 
>>>> some C embedded device.  I use pieces from my GUI app and also 
>>>> javabridge which has to be 32-bit to agree with the TI Code Composer 
>>>> Studio which is only available as 32-bit on Windows presently (and 
>>>> only 64 on Linux...  *sigh*).
>>>> How much effort is it to maintain the 32 bit wheel build?  Any 
>>>> chance of getting a copy of the reference wheel build script you 
>>>> use?  It seems like we could setup automated builds (including 
>>>> snapshots) and probably get some community support to keep them 
>>>> going.
>>> The effort is maintaining 4 development environments rather than 3
>>> which is made worse by Windows being such a pain.
>>> The "wheel build script" is an integral part of an internal build and
>>> CI system. I am (slowly) moving towards being able to have source
>>> packages on PyPI - but that would require you to have Qt already
>>> installed.
>> 
>> I presume that the source package would make it fairly easy to build 
>> our own wheels.  Even if it didn't provide support for a given 
>> platform somehow, at least the 'automated' build would be available 
>> publicly for modification and patches could be submitted (and maybe 
>> accepted).  That would be a great step forward in my opinion.  The 
>> lack of any reference builds has certainly been frustrating for me (or 
>> I'm just silly and missed it).
> 
> I don't know what you mean by reference builds.

Lots of open source projects have public CI (such as on Travis) which 
let's you see an exact set of commands and their exact results (and how 
they have been changed between versions).  It's good to have 
documentation describing various options but it is also nice to be able 
see an actual set of commands that build the code and see what 
environment it is that they work in.  Additionally, when people make 
contributions they can have them built and tested in the same automated 
environment to try to avoid other regressions.

Cheers,
-kyle
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]