OSX native build

[yousseb]

This pull request is coming a bit late since my initial announcement on the mailing list, but I guess it's better late than never.

There are some hacks related to the build/packaging process that can be improved, but the python code changes are clean. I'm hoping that getting into the official repo would allow people to help with the hacks in the packaging process.

Thank you for meld.

[kaiw]

So I'm keen to get this in, but I'm also likely to be fairly careful about it. My concern here is simply that once in it's going to be a new platform to be maintained, and we don't have the resources to really do this. Having said that, I think that the vast majority of these changes are fine and don't really mess with anything else in Meld.

It would make it a lot, lot easier to apply this if you could rebase (on a new branch or whatever) these changes into sensible chunks. For example, if you put your cleanup of the accelerator keys into a standalone patch, I'll happily apply that straight away. Everything under the osx/ directory seems fine (or at least carries zero risk).

I wish we didn't have to have a third setup.py file, but I can live with that for now. However, there seems to be setup duplication between it and setup.cfg. I feel like we can do without the .cfg file, which would make me happier here too.

I'm not sure I understand why the menu special-casing is required, since I thought that GTK+ handled this for us, but I admit I haven't tried the OSX integration in years.

[yousseb]

Kai,

1- I'll try to do the splits over this weekend.
2- I think we can lose the setup.cfg file, but the third setup.py is necessary.
3- Special casing for OSX Menu is really needed, unfortunately.

Regards,
Youssef

[yousseb]

Kai,

I just opened #12, #13, #14 to split this pull request into three stages. Should be easy to merge. I removed removed setup.cfg as agreed. Once you merge those pull requests,

1. I'll rebase and start work on cleaning up the OS X build script
2. I'll work on removing OS X shell wrapper that feeds the Python/GTK that we bundle in the final package the environment variables. I'll use the conf.py frozen method to set the environment variables which thankfully happens before importing GTK. This will happen by checking first if we're running in Quartz (not only OS X to provide MacPorts and other variants to continue to use the paths the same way they do now)
3. The is_darwin method will be upgraded so that it checks that the OS is OS X and the windowing environment is Quartz. Again, this is to allow MacPorts and others to work without patching. Note that MacPorts latest version of Meld is still 1.8.

Regards,
Youssef

[kaiw]

Just wanted to say that I still want the rest of this in. However, I'm trying to get a build machine that I can test on before merging #13. I won't merge #14 before I get to releasing Meld 3.16, since that will mess with other OSX-based Meld build. As you say, MacPorts, etc. are still on Meld 1.8, but there are plenty of people using the Brew-based builds.

[yousseb]

Kai,

I intend to do some updates to this soon so that meld would check if it's
running on gtk using quartz backend. This is the only unique part that
differentiates those patches from brew and all the rest which depend on
XQuartz (X backend). However I'm very low on time these days.

Note that even when you get your hands on a build machine, the preparation
of the build environment is very time consuming - expect something in the
vicinity of four or five hours. You'll also require about 6GB free disk
space.

Thanks for your interest..

Regards,
Youssef

On Sun, Mar 20, 2016 at 10:53 PM, Kai Willadsen notifications@github.com
wrote:

Just wanted to say that I still want the rest of this in. However, I'm
trying to get a build machine that I can test on before merging #13
#13. I won't merge #14
#14 before I get to releasing Meld
3.16, since that will mess with other OSX-based Meld build. As you say,
MacPorts, etc. are still on Meld 1.8, but there are plenty of people using
the Brew-based builds.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#11 (comment)

[gnomesysadmins]

Thank you for contributing to meld!

meld uses Bugzilla for code review.

If you have never contributed to GNOME before make sure you have read the
getting started documentation:
http://www.gnome.org/get-involved

Otherwise please visit
https://wiki.gnome.org/Newcomers/CodeContributionWorkflow
and follow the instructions there to upload your change to Bugzilla.

[kaiw]

@yousseb I'd reopen this, but given this is a bot close it won't do any good. I'm still interested in getting this merged one day, but still have no build machine and I see that the branch hasn't been updated in a while.

If you wanted to isolate easy-to-merge patches I'll get what I can in to reduce the difference between upstream and your branch, and then see where we get to. I'll happily review any patch series that you want to post to bugzilla or the mailing list. Thanks again.