Re: Update Windows binaries

[Keegan Witt <keeganwitt gmail com>]

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.

Vasily, You didn't need to change the path of TK_LIBRARY and TCL_LIBRARY between 32 and 64 bit?  And you're saying Msys2 has leftovers between runs?  I thought it started with a fresh VM each time?

-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