回覆: Outdated win32 bundle

["Fan, Chun-wei" <fanc999 yahoo com tw>]

Hi,

As Nacho mentioned in his earlier email on this topic free days ago, there is a bug in the introspection part that is working on getting introspection to work better on Windows, 728313, which I checked lady week the patches there still applies to the latest git master, which is still pending further review, and it should make introspection more portable, by using items from python itself(namely, distutils)

I am also working on a master solution file which contains various msvc projects that will build the dependencies of the GTK+ and GTK+ itself (2.x and 3.x).  This is still wip, at github.com/fanc999/gtk-msvc-projects, and I will let people know when it's ready for use.

With blessings.

---

寄件者: Emmanuele Bassi
寄件日期: ‎2015/‎6/‎19 07:24
收件者: Daniel Kasak
副本: Gian Mario Tagliaretti; GTK Devel List; anatoly techtonik; ML-gtk
主旨: Re: Outdated win32 bundle

Hi;

sorry to use Daniel's email, but since this thread keeps growing, I'm
just using the latest entry point to try and give some actionable
items.

It's all well and good that everybody has their own builds, and
packages, and installers — and I mean it: it's great to see so much
activity around GTK on Windows. Now, if only that translated to more
contributions to the backend code… *wink* *wink* *nudge* *nudge* ;-)

While people doing their own builds is great, I'm still going to ask
for one thing: please, help out setting up an automated builder that
takes the GTK git repository and builds it with the Windows backend.
Running the test suite would even be amazing, but I'd settle for
verifying that commits do not break the Windows backend.

Seriously: if you are an app developer that already has a build
environment for GTK, then you're already set. You don't have to change
anything in your workflow — though you'll be advantaged by a
continuous integration system that at least verifies that each release
of GTK builds on Windows (and possibly does not regress, any more that
it may regress on Linux).

The GTK team does not, currently, have the capacity to set up this CI
system. Nor it has the capacity for building binary distributions of
the libraries for Windows. That's why my strong suggestion, after
speaking with the people that are *actually* working on the Windows
backend — namely Ignacio and LRN — is to concentrate efforts in the
infrastructure to verify that the Windows backend does not break with
every release, or every commit. Application developers relying on a
binary distribution coming from gtk.org in the past have different
options for getting a replacement — they have been listed in this
thread. If you want to help the GTK in improving the Windows support
then you can:

 * work on the infrastructure, in a way that can be automated and
maintained even if you happen to leave the project
 * work on the Windows backend itself, by triaging old and new bugs;
fixing them; catching regressions during the development cycle; or
implementing new features
 * work on improving jhbuild use on Windows
 * work on improving introspection on Windows

These options are not mutually exclusive; they are *all* important.

So, let's try and get to something actionable. Can somebody try and
set up a CI for GTK that either cross-compiles GTK or compiles it
natively? Both aspects are important — as Daniel pointed out,
cross-compiling the introspection data is currently not possible, so
that leaves out dynamic languages like Python, _javascript_, and Perl;
plus, it does not allow us to run the test suite. Cross-compilation is
fine for an auto-builder that verifies that commits are not breaking
the build on Windows, which is a good start.

Another actionable point: helping out triaging the Windows-related
bugs on Bugzilla. What's still relevant? What's obsolete? If there are
patches, are those still applicable, or can they be rebased? Does a
bug filed against GTK 2.x still affect GTK 3.x?

Is anybody willing to help out Ignacio and LRN with the missing
functionality of the Windows backend?

What about jhbuild? Can somebody set it up on Windows and file bugs
whenever something breaks?

Ciao,
 Emmanuele.


On 18 June 2015 at 23:49, Daniel Kasak <d j kasak dk gmail com> wrote:
> Hi all. I've got my own builds of Gtk+ for Windows, available at:
> http://tesla.duckdns.org/jewelkit-1-0-released/ ( I have another build
> I'm ready to upload in the next week actually ).
>
> This contains perl as well as Gtk+. I make regular releases (
> currently ). I also have a bunch of patches I've been meaning to
> submit ( fixing build issues ). In particular, the object
> introspection stuff is a MAJOR PITA to build on Windows, and AFAIK is
> impossible to build in Linux with a cross-compiler.
>
> It would be fantastic if building Gtk+ ( and bindings ) on Windows
> were "far less painful" ... and better yet if there were official
> installers ... though I guess that's asking a bit much for
> corner-cases like perl developers' needs :)
>
> Dan
>
> On Fri, Jun 19, 2015 at 4:20 AM, Tarnyko <tarnyko tarnyko net> wrote:
>> anatoly techtonik writes:
>>>
>>> On Fri, Jun 12, 2015 at 2:42 PM, Emmanuele Bassi <ebassi gmail com> wrote:
>>>>
>>>> On 12 June 2015 at 12:27, anatoly techtonik <techtonik gmail com> wrote:
>>>>>
>>>>> On Thu, Jun 11, 2015 at 4:15 PM, Emmanuele Bassi <ebassi gmail com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Currently, we advertise ad hoc Windows builds on gtk.org; those are
>>>>>> out of date, and lack many of the bug fixes that went into GTK.
>>>>>
>>>>>
>>>>> I see two problems here:
>>>>> - [ ] http://www.gtk.org/download/win32.php - doesn't say this info
>>>>> - [ ] http://www.gtk.org/download/win32.php - doesn't have a link to
>>>>>       the site source to fix that
>>>>
>>>>
>>>> Yes, that's why I said:
>>>> | The current stance of everyone involved in the Windows backend for
>>>> | GLib and GTK+ is to stop advertising binary builds for Windows
>>>> There's also a bug about this:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=747742
>>>> It would be good to fix the website to reflect the reality.
>>>
>>>
>>> That's not that I mean. I mean that the site will not be fixed if there is
>>> no visible way to fix that. Can we solve this problem first? Where is the
>>> site source and what is the process to add the source link (along with
>>> description of the site update process) to the site footer?
>>>>>
>>>>> Points that are also missing to enable me (or anybody else) to
>>>>> fix the situation:
>>>>> 1. Is it possible to make "lack many of the bug fixes that went into
>>>>> GTK"
>>>>>     a link to actual list?
>>>>
>>>>
>>>> The "actual list" is published with each release of GTK+.
>>>
>>>
>>> That means that data about all previous versions need to be updated
>>> with new fixed bugs. Is the publishing process automated enough to
>>> allow this?
>>>>>
>>>>> 2. How to detect automatically that builds listed on the page are out
>>>>>     of date?
>>>>
>>>>
>>>> There are no new builds. The last build for Windows was for GTK+ 3.6,
>>>> which, as of today, is two and half years old.
>>>
>>>
>>> The question assumes that. When the build becomes out of date?
>>>>
>>>> The website needs to be changed to reflect the reality of the project,
>>>> not the past.
>>>
>>>
>>> Marking old releases as outdated does just that.
>>>>>>
>>>>>> This
>>>>>> situation is confusing for application developers, and makes the
>>>>>> project look bad. It also reflect badly on the great work that
>>>>>> developers have been doing in order to make GTK work well on Windows.
>>>>>
>>>>>
>>>>> Editing the site with heads up on the situation and an entrypoint
>>>>> to change it would make it better.
>>>>
>>>>
>>>> Indeed it would.
>>>
>>>
>>> I am glad there is no misunderstanding between us here. =) Can we now
>>> make an actionable item out of it? So that it is clear for everybody how
>>> to
>>> do this and what to do exactly as a next step.
>>>>>>
>>>>>> On top of that, we don't offer binary builds for any other platform,
>>>>>> and instead rely on distributors — like Homebrew on Mac; the *BSD
>>>>>> ports; or the various Linux distributions — to provide binary builds
>>>>>> for them. Windows is an anomaly, mostly because there weren't
>>>>>> good/usable software distributions in the past. This has now changed,
>>>>>> and it's a good thing to ensure that developers on Windows get
>>>>>> reliable, up to date software.
>>>>>
>>>>>
>>>>> You're speaking about Chocolatey or about Steam? =)
>>>>
>>>>
>>>> I'm talking about MSYS2.
>>>
>>>
>>> I think that the concept of package managers for Windows is flawed,
>>> but it is just my opinion as a Windows user with 10+ years experience.
>>>>>>
>>>>>> MSYS2 is for developers, not for end users.
>>>>>
>>>>>
>>>>> Ok. Still I don't get it. I wanted a local directory install for GTK
>>>>> libs for
>>>>> compiling Wesnoth. I don't want system global install of MSYS2 - I
>>>>> already have MinGW unpacked locally and building with SCons. Is that
>>>>> possible?
>>>>
>>>>
>>>> That's possible if you build GTK+ for yourself.
>>>
>>>
>>> But that is possible with current binary downloads. That's a regression
>>> and
>>> vendor dependency on MSYS2 project. For project like Wesnoth GTK is one
>>> of the dozen possible dependencies and exclusive requirements and
>>> processes for every dependency makes life of a build system integrators
>>> a nightmare.
>>>>
>>>> There have been no binary builds of GTK+ since January 2013, but there
>>>> have been five new development cycles, so if you want to use an up to
>>>> date version of GTK+, your current choices for building your
>>>> application on Windows are either to build GTK yourself, alongside its
>>>> dependencies, or use MSYS2 and its packages.
>>>
>>>
>>> I don't want to use MSYS2. My build chains is completely unattended. Here
>>> is where I download MinGW + GTK:
>>>
>>> https://bitbucket.org/techtonik/locally/src/48cd31a64c9ec8b198e2b4c9d394d43c45d65bcd/05.wesnoth.py?at=default#cl-37
>>> and here is where I setup it:
>>>
>>> https://bitbucket.org/techtonik/locally/src/48cd31a64c9ec8b198e2b4c9d394d43c45d65bcd/05.wesnoth.py?at=default#cl-539
>>> Using binary installer complicates this process with no benefit.
>>>>>>
>>>>>> Telling your users to download your application; download DLLs from
>>>>>> gtk.org; shove them into some directory; and, finally, hope for the
>>>>>> best, was never a good software distribution mechanism.
>>>>>
>>>>>
>>>>> What about developers? I find it much better workflow when DLLs are
>>>>> local to the project being built rather then installed globally, because
>>>>> often you need to test several lib versions for testing different bugs
>>>>> and
>>>>> branches.
>>>>
>>>>
>>>> That's what I said above.
>>>
>>>
>>> So, you can't do that with MSYS2 install and will have to rebuild the
>>> GTK from scratch anyway for that use case. That looks like a no-go
>>> for MSYS2 for me.
>>>>>>>
>>>>>>> Can GTK be cross-compiled for Windows?
>>>>>>
>>>>>>
>>>>>> Yes, it can, and it routinely is.
>>>>>
>>>>>
>>>>> Is there a single command to run to do this?
>>>>
>>>>
>>>> There isn't. On Fedora you can use the mingw(32|64) toolchain packages
>>>> to build your own packages.
>>>
>>>
>>> That's another problem that can be solved.
>>> - [ ] provide a single command for cross-platform build of GTK for Windows
>>> I can try to automate the process - the script I used for Wesnoth became
>>> a good source of copy/paste automation.
>>>>>
>>>>> But it should be compiled using MinGW, not Visual Studio, right?
>>>>> Because appveyor is the only known CI service (to me) that compiles
>>>>> the stuff with VS.
>>>>
>>>>
>>>> Visual Studio is another beast entirely.
>>>> The GNOME Foundation kindly provided us with a VM that we can use to
>>>> do Windows builds — which is what Tarnyko was using — using
>>>> cross-compilation.
>>>
>>>
>>> So, VM is not running Windows if we're speaking about cross-compilation,
>>> right? What happened to it?
>>
>>
>> VM still exists, but is inactive at this very moment. It used a chain of
>> scripts to build the Win32/Win64 bundle with MinGW. Visual Studio would
>> require a Windows machine, better not consider it until the rest works well.
>> I fear me stepping down from the project has switched the project's concern
>> from using the VM for releasing "bundles" to using it for hosting a
>> continuous integration system. Anyways, a reproducible/reinstallable CI
>> would allow you to rebuild any version of GTK+3.
>>>
>>>
>>> --
>>> anatoly t.
>>> _______________________________________________
>>> gtk-list mailing list
>>> gtk-list gnome org
>>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>> Regards,
>> Tarnyko
>>
>> _______________________________________________
>> gtk-list mailing list
>> gtk-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list



-- 
https://www.bassi.io
[ ] ebassi [ gmail com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list