Re: Update Windows binaries

[Vasily Galkin <galkin-vv yandex ru>]

Hi!

> Pacman does allow you to pin versions just like you can in other package management systems (like apt). You 
> do that like pacman -S bash==3.2. But obviously the pinned version must be available in the repos used.

After trying this locally I'm not sure that installing non-last package version is officially supported for 
msys2.
While *one* of the msys2 mirrors indeed contains older packages like
http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-gtksourceview3-3.24.6-1-any.pkg.tar.xz

Such packages can't be installed after database updating with pacman -Sy

As of today this command works (current version):
pacman -S mingw64/mingw-w64-x86_64-gtksourceview3=3.24.6-2
And this  doesn't(for previous version):
pacman -S mingw64/mingw-w64-x86_64-gtksourceview3=3.24.6-1

> Vasily, You didn't need to change the path of TK_LIBRARY and TCL_LIBRARY between 32 and 64 bit? 

The only usage of (tcl & tk) in meld is displaying message box about gtk/glib absence via tkinter for a case 
gtk/glib is not installed. It is useful for running meld 3.18 from checkout, but doesn't look useful for 
installer.
So I just add tkinter module to excludes in setup_msys2.py, so tcl & tk is not included in installer at all. 
My latest changes are here https://gitlab.gnome.org/galkinvv/meld/tree/meld-installer-build
(installer mostly works but code still a bit hard-to-mantain and history is bit hard-to-read)

> And you're saying Msys2 has leftovers between runs? I thought it started with a fresh VM each time?

The entire VM is fresh, but there is a parameter in appveyor-msys2.yml
cache:
  - C:\meld-build-cache

It allows caching network data on appveyour instead of redownloading it every time.
The need to download is checked manually from meld/ci_helpers.py

In addition to "manual pinning" of msys packages this allows making *re*builds depending only on availability 
only of 2 servers (meld git, appveor ci) instead of 3 (meld git, appveor ci and msys2 repo).


> -Keegan

> On Sat, May 26, 2018 at 6:49 PM Kai Willadsen <kai willadsen gmail com> wrote:
>
> > On 19 May 2018 at 05:46, Vasily Galkin <galkin-vv yandex ru> wrote:
> >
> > > Hello again!
> >
> > > Due to recent pangocairo changes in mingw-msys2 meld 3-18 become incompatible with it (even running from 
> > > checkout).
> >
> > Honestly, I think it's unlikely that moving 3.18 to msys2 is worth it.
> >
> > The current Windows builds work (even if the pipeline doesn't _really_
> >
> > work for publishing them) and that's better than new issues from an
> >
> > msys2 change.
> >
> > > So I cherrypicked last changes Keegan Witt made for 3-18 (thanks!) changes to new branch created from 
> > > current master, fix pangocairo and make some more adjustments:
> >
> > > - fixed paths to glib data installation
> >
> > > - XDG_DATA_DIR separator
> >
> > > - added caching of msys packages in appveyour data to achieve build stability on rolling-release msys2
> >
> > I don't know much about msys2... does it not have a way of pinning
> >
> > package versions?
> >
> > > - remove libwebp (it looks unused?)
> >
> > It will just be there as a gdkpixbuf loader. We don't load webp
> >
> > images, but if in the future we e.g., added image diff or something,
> >
> > then we'd probably want to put it back.
> >
> > > - unified. renamed mingw64+32 scripts in single msys2 script
> >
> > >
> >
> > > The repo with scripts is here - 
> > > https://gitlab.gnome.org/galkinvv/meld/commits/65f5c2fe1d4564a40fb47247a996eff6417ff74d
> >
> > > (meld-installer-build branch)
> >
> > > The resulting installer is here:
> >
> > > https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/jja76xhc0qxdq461/artifacts
> >
> > Awesome! thanks. This looks like a huge step forward to me, and I'd be
> >
> > keen to merge it whenever you think it's ready. In fact, given that
> >
> > right now 3.19 doesn't work at all, I think we can be pretty generous
> >
> > with what "ready" means.
> >
> > It's also worth noting that it's *possible* that we might be able to
> >
> > do this building on the GNOME Gitlab instance in the future (instead
> >
> > of Appveyor). I don't think this changes anything about what you've
> >
> > written, since the steps will be 90% the same, and I would rather get
> >
> > something working now.
> >
> > > This installer installs meld master (3.19-based) and the resulting installation behaviour is identical to 
> > > meld executed from checkout on msys2:
> >
> > > - It mostly works if executed from cmd line with files arguments (works 80% of time, but may crash or 
> > > hang)
> >
> > > - for up-to-date msys2 version meld master has huge problems with selection&comparing files via new tab 
> > > page, at least on windows 7.
> >
> > Is the issue to do with Meld, or is it the file selector itself?
> >
> > > So it looks that installation build scripts themselves are mostly correct and this version achieves basic 
> > > windows compatibility for current master with msys2.
> >
> > > The commit history of achieving this compatibility mostly contains trial&error commits.
> >
> > > Should the commit history be included in merge request or squashed to single commit describing ideas of 
> > > most important changes?
> >
> > I had a read through that branch, and while I think the commit history
> >
> > + messages could be cleaned up a bit (if you're comfortable with
> >
> > interactive rebase) there's nothing wrong with having the full history
> >
> > there. I'd probably prefer that to having a single squashed commit.
> >
> > cheers,
> >
> > Kai
> >
> > _______________________________________________
> >
> > meld-list mailing list
> >
> > meld-list gnome org
> >
> > https://mail.gnome.org/mailman/listinfo/meld-list