On 24/apr/2014, at 17:55, Dick Hollenbeck <[email protected]> wrote:
Dick
I’m there, i wish ask to you and bug reporters to send a mail in CC directly to
me if there are urgent and important things about OSX.
I’ven always the time to read the Developer ML during my work peaks, sorry.
> Marco (or in his continued absence, any other OSX developer),
>
> 1)
> After reading for a few minutes about app bundles on wikipedia, I am thinking
> we can
> eliminate the copy of the *.kiface file which is up at the directory where
> the *.app files
> exist.
>
> Do you agree?
>
> If so, please look at this patch as a proposed strategy for all but the
> kicad.app. This
> only deals with pcbnew.app as a trial balloon. The trick is to build the
> *.kiface module
> down in the bundle right out of the get go. I am curious if it gets copied
> properly
> during the install. I have no way to test that since this is OSX CMake
> specific behavior.
Dick why you wish do that, which is the improvement that that could do to the
current way ?
The current arrangement works nice with 3 releases of OSX testing it all will
mean days of testing.
> 2)
> For the kicad.app/Contents/MacOS/ directory, I would suggest we install
> symlinks with
> these names
>
> _pcbnew.kiface, _eeschema.kiface, _cvpcb.kiface to the real deals up and over
> in the
>
> pcbnew.app/Contents/MacOS directory equivalents.
>
> I don't know how to do this with CMake yet. But we should try it manually
> first. This
> will leave us with one copy of each *.kiface binary.
>
> I think I know how to create the symlinks in the build directory copy of the
> bundle, so I
> wonder if during install these would get transformed to actual full copies.
>
> The difficulty is that the ${KIFACE_BIN} variable does not get expanded
> before the
> install() steps are actually done. In fact it looks like it happens inside
> the install()
> steps. So there's no way to get an expanded variable during installation.
>
> So let's hope setting up the symlinks in the build dir will get carried into
> the install dir.
If i’ve understood well the point 1) is propaedeutic for this step.
This makes the debug also more difficult and render impossible make symbolic
links in the build tree.
/product/pcbnew/pcbnew.app/[…]
is different of in place
/Applications/Kicad/pcbnew.app/[…]
There is a directory level of difference with the consequent difference in the
“relative path” that is the strategy that we should point to and we shall pass
to the ln command.
Moreover, we will introduce a dependency of the bundles to another one.
This is the “ratio" of the integral copy of .kiface libraries and not the
linking.
And the reason that induces me to discourage that changes.
Moreover the final step of the kiway operation points us to have a single
bundle in small time: the problem will be resolved naturally.
Does this change worth the costs to debug bugs for symbolic links pointing to
nowhere that are also difficult to trace via mail/bugtracker ?
—
Marco
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
