Hey,

I have a simple fix for issue #354, I posted a comment on the issue page.

Are there some basic guidelines for testing code changes? How much checking
should I be doing of, for example, path formats and stuff like that?

Also I am a bit unsure about the cleanest way to do a code submission after
a fix, should I check out a whole new clean source to make the changes in
to avoid polluting it with random stuff?

Regards,
Adam

On Wed, Aug 5, 2020 at 4:10 PM Adam Antium <[email protected]> wrote:

> Hi Vasily,
>
> Great instructions, thanks a lot! It's all working, I will start playing
> around with the code and check out some of the open issues.
>
> Regards,
> Adam
>
> On Wed, Aug 5, 2020 at 2:54 PM Vasily Galkin <[email protected]> wrote:
>
>> Hello!
>> In short: to get dependencies install Msys2 on windows and install its
>> packages:
>>
>> pacman -S mingw-w64-i686-python3-cx_Freeze mingw-w64-i686-python3-gobject
>> mingw-w64-i686-python3-pytest mingw-w64-i686-gtksourceview4
>> mingw-w64-i686-gsettings-desktop-schemas glib2-devel intltool
>>
>> In more deatils: the best-tested way to create meld build environment on
>> windows is creating environment similar to the one created by the gitlab CI
>> system.
>> It is defined in
>> https://gitlab.gnome.org/GNOME/meld/-/blob/master/.gitlab-ci.yml
>>
>> Meld works & builds fine not only on mingw-w64 32bit, but also on
>> mingw-w64 64bit.
>> Such builds are already performed in gitlab CI, but not published.
>> So the .gitlab-ci.yml is a bit non-linear since it describes both 64-bit
>> and 32-bit builds.
>>
>> The desctiption below is interactive-usage adaptation of the
>> .gitlab-ci.yml
>>
>> For beginning developing meld on windows these are typical steps (for
>> 32bit; 64-bit is similar):
>> * Install msys2 from https://www.msys2.org/
>> * update it to latest versions of all components: pacman -S --refresh
>> --sysupgrade
>> * install dependencies for developing meld: pacman -S
>> mingw-w64-i686-python3-gobject mingw-w64-i686-python3-pytest
>> mingw-w64-i686-gtksourceview4 mingw-w64-i686-gsettings-desktop-schemas
>> glib2-devel intltool git
>> ** note: there is meld package in msys2 repos. It is fine, but if you
>> planning to develop meld itself  - do NOT install (or uninstall if already
>> installed) mingw-w64-i686-meld3 package, otherwise sometimes files can be
>> used inconsistently (some from dev. copy and some from that package)
>> ** you may also want to install mingw-w64-x86_64-gedit - it uses
>> gtksourceview, so for some issues sometimes its useful to compare meld &
>> gedit behaviours.
>>
>> * Simplest meld execution:
>> * open mingw32 shell
>> * clone meld repo and cd to its root
>> * from there run: bin/meld
>> ** meld should open its window and running fine without any errors. If it
>> failed for some reason - the later steps would not work too, so in such
>> case stop here for investigation
>> ** runing this way is the fastest way to develop and 80% of issues
>> not-related-to freezing and system specifics can be developed this way
>> ** to test this mode integration with external programs lke TortoiseSVN
>> the similar run-meld.cmd can be helpful:
>>        D:\apps\msys2\mingw64\bin\python3.exe D:\apps\meld-git\bin\meld %*
>>
>> * For building msi installer run:
>> ** glib-compile-schemas data
>> ** python3 setup_win32.py bdist_msi
>> *** it can be quite slow, 1-5 minutes preparing + 1-5 minutes to install
>> msi (upgrading msi is a LOT slower that first install due to uninstalling
>> lots of adwaita icons)
>>
>> * For faster build that produces result folder similar to installation
>> result without actually slow-packing+slow-unpacking msi, run:
>> ** python3 setup_win32.py install --prefix $(pwd)/some-folder >
>> install-output
>> ** this is very similar to actual msi install, the known differences are:
>> folder path (with/without spaces), start menu icon, and (nearly-unused)
>> registry values
>> ** so 99% of issues can be developed this way
>> ** there is a known behaviour difference on runing Meld.exe from msys2
>> shell (with MSYSTEM variable) and from any shell without MSYSTEM variable,
>> like explorer. Some changes require testing both cases.
>>
>> melds' gitlab CI also has some python lint (some coding style etc)
>> automatic check.
>> I think it can be configured to run locally on msys2, but actually I
>> never did it (was looking to lint failures only after pushing to my fork...)
>> --
>> Regards,
>> Vasily
>>
>> > Hey,Thanks to Heikki for his suggestion.
>> > I'm currently trying to run a windows build, however it's turning out
>> to be a bit complicated setting up the requirements, is there a preferred
>> method for installing all of that? And a preferred source for all of the
>> packages?
>> > Regards,
>> > Adam
>> >
>> > On Tue, Aug 4, 2020 at 7:17 PM Heikki Ketoharju <
>> [email protected]> wrote:
>> >
>> >> Hello!
>> >>
>> >> I wondered the same thing two years ago and it turned out there's a
>> "Newcomers" label in Gitlab issues. I picked one from there, solved it and
>> it was fun! Also it felt good to see my commit approved later on.
>> >>
>> >> Here you can find the labelled issues. I warmly recommend!
>> >>
>> >>
>> https://gitlab.gnome.org/GNOME/meld/-/issues?label_name%5B%5D=4.+Newcomers
>> >>
>> >> kind regards,
>> >> Heikki Ketoharju
>> >> (another newcomer, and currently just a passive contributor)
>> >>
>> >> On Tue, 4 Aug 2020 at 18:16, Adam Antium via meld-list <
>> [email protected]> wrote:
>> >>
>> >>> Hey,
>> >>> I'm interested in making some contributions to the project.
>> >>>
>> >>> I don't have any experience with open source work but I like Meld and
>> I'd like to help, any suggestions on where to start?
>> >>>
>> >>> Regards,
>> >>> Adam
>> >>>
>> >>> _______________________________________________
>> >>>
>> >>> meld-list mailing list
>> >>>
>> >>> [email protected]
>> >>>
>> >>> https://mail.gnome.org/mailman/listinfo/meld-list
>>
>
_______________________________________________
meld-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/meld-list

Reply via email to