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.willad...@gmail.com> wrote: > On 19 May 2018 at 05:46, Vasily Galkin <galkin...@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 >
_______________________________________________ meld-list mailing list meld-list@gnome.org https://mail.gnome.org/mailman/listinfo/meld-list
