kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

On 24/apr/2014, at 17:55, Dick Hollenbeck <dick@xxxxxxxxxxx> 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