Fixing library references in all mach-o files

[fmorgner]

In this version, step7 additionally fixes the wxWidgets library references in all mach-o files in the project.

[adamwolf]

Awesome. I'll get these building on my 10.6 box soon, so we have
builds that work on 10.6, 10.7, and 10.8

On Sat, Apr 20, 2013 at 7:12 PM, Felix Morgner notifications@github.com wrote:

In this version, step7 additionally fixes the wxWidgets library references
in all mach-o files in the project.

---

You can merge this Pull Request by running

git pull https://github.com/fmorgner/KicadOSXBuilder master

Or view, comment on, or merge it at:

#3

Commit Summary

added step to fix the library references in all mach-o files

File Changes

M build.sh (55)

Patch Links:

https://github.com/mangelajo/KicadOSXBuilder/pull/3.patch
https://github.com/mangelajo/KicadOSXBuilder/pull/3.diff

[fmorgner]

Thanks. Maybe you need to change line 282 for the 10.6 build. I think i should have gone a safer way from the beginning. Please let me know if you find any issues.

[adamwolf]

I have some changes I had to make for 10.6, but I can merge them into
this. Thanks!
On Apr 20, 2013 7:53 PM, "Felix Morgner" notifications@github.com wrote:

Thanks. Maybe you need to change line 282 for the 10.6 build. I think i
should have gone a safer way from the beginning. Please let me know if you
find any issues.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3#issuecomment-16714029
.

[fmorgner]

Ok. I'm currently investigating an issue that, to me, seems to stem from the shell script wrappers. It seems like MacOpenFile is never getting called when the app is opened through the wrapper. But maybe I'm wrong and its some issue on my side.

[adamwolf]

Does this version work when launched from Spotlight? A user reported that
they had issues with that but not when launched from the Finder.
On Apr 20, 2013 8:09 PM, "Felix Morgner" notifications@github.com wrote:

Ok. I'm currently investigating an issue that, to me, seems to stem from
the shell script wrappers. It seems like MacOpenFile is never getting
called when the app is opened through the wrapper. But maybe I'm wrong and
its some issue on my side.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3#issuecomment-16714151
.

[fmorgner]

Yes this version launches fine via Spotlight. It was me who reported the issue and I was totally wrong with it. It was my fault, i wasn't launching the packaged up version but one of the version lying around in the build directory. I just realized that today, silly mistake.

I'm currently investigating the possibility of setting the Environment variables via the LSEnvironment key in the Info.plist but it seems like I'm currently out of luck. It seems like the environment variables never make it into the environment.

[fmorgner]

Ok, seems like I was wrong again. MacOpenFile gets called even when we use the shell script wrappers. The problem seems to be in the implementation of MacOpenFile of kicad, since i can confirm that at least in pcbnew it works correctly.

[kicadhub]

Awesome work as usual Felix!!, we're getting the build better and better, please confirm when it's safe to pull, and I'll do it :-)

Thanks for your work in 10.{6-8} too Adam!! :)

👍

Is the new commandline 'python' wrapper working too? :)

it's supposed to be called from osx terminal, to let you use pcbnew scripts from commandline :)

[fmorgner]

I can confirm that the script builds fine. I've got a version of kicad built with this version of the script up and running fine.

[fmorgner]

BTW i just submitted a patch to the mailing list regarding the file opening issue on OSX. The implementation of MacOpenFile was a little quirky but it works now.

[mangelajo]

My python wrapper installation got lost somehow

(this before zip)
cp -rfp $PATCH_DIRECTORY/python $PACKAGE_DIRECTORY/KiCad/

I'm going to merge, and then add this line, it's supposed to be used this way:

export PATH=/Applications/KiCad:$PATH

python

[mangelajo]

About the patch in the mailing list, we will need to confirm that it doesn't affect other platforms.

I readed it, but I must confess that I don't understand what you're doing :)

PS: Also be ready to hear screaming voices about the coding policy, if at some moment in future you want to become a regular contributor to the kicad maincode I recommend you to read the kicad coding style policy (not long)

Thanks again Felix!! :)

[fmorgner]

I think, but as you said we need to prove it, that the patch should not influence other architectures, since it's in a method thats only called
under OS X. It is a pretty basic thing, after m_ProjectFileName is set to fn and some error checking is done, I'm triggering a load event so that
the loading is handled via the existing project loading routine.

Regarding the coding style, I can't seem to find a place where I'm not adhering to it, could you please specify more precisely where I'm wrong?

Thanks!

[mangelajo]

The coding style thing (very peculiar, I've only seen it in KiCad by now) it's:

loadEvent.SetId(wxID_ANY) -> loadEvent.SetId( wxID_ANY )

and the OnLoadProject( ... )

Yet don't understand what's the patch fixing exactly, what's the bug?

what was the expected behaviour, and what was what it did?

I will check it and submit the patch, but I'd like to understand it :)

[fmorgner]

Ahhhh i didn't catch those white-spaces.

The patch fixes the file opening from Finder in OSX.

Prior to the patch, if you double clicked on a KiCad project file kicad would open but the file would not be loaded instead the
last opened project was opened. This patch fixes this in that it calls "OnLoadProject" with an event off type wxID_ANY. This
causes that the internal (as in already implemented in "OnLoadProject") loading routine takes care of loading the project file.

MacOpenFile only gets called when a wxWidgets application is launched via Launch Services with a file as an argument,
i.e. a file associated with this application is double clicked in Finder.

Am 22.04.2013 um 17:10 schrieb mangelajo notifications@github.com:

The coding style thing (very peculiar, I've only seen it in KiCad by now) it's:

loadEvent.SetId(wxID_ANY) -> loadEvent.SetId( wxID_ANY )

and the OnLoadProject( ... )

Yet don't understand what's the patch fixing exactly, what's the bug?

what was the expected behaviour, and what was what it did?

I will check it and submit the patch, but I'd like to understand it :)

—
Reply to this email directly or view it on GitHub.