kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/27/2014 07:36 AM, Marco Serantoni wrote:
> 
> 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.



This is in the thread between me and Jean-Paul.  Having a *.kiface file in the same place
as the *.app is located, and then again two directories down seemed sloppy to me.  So
clearly neither Jean-Paul or myself thought it was a good idea and unnecessary for his
version of OSX.

Is this needed for a particular version of OSX, or was it just as quick, sloppy hack to
get the kiface in any place it *might* be needed?




> 
> 
>> 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.

There is only one Kicad application as far as I am concerned.  Bundles are something that
gets in my way, and would be like treating eeschema and pcbnew as two different linux
packages.  They are not.  It is one application suite, made even more tightly bound by the
KIWAY.

So I don't see your argument, at least not based on bundles.  However I suffer no
particular loss if Mac users want to use more disk space than needed, and you want another
copy of the *.kiface files in the kicad.app tree.  And I remind the list, that this would
bring the total under your scheme to 3 copies of each *.kiface, vs. one copy of each using
my patch, if it works.

Really I don't care.  However, I do find it disrespectful that after I spent a whole day
with Jean-Paul offline solving the issues for him on his machine manually, that no one has
had the courtesy to actually try my patch to see if it even works.

This is clearly another example of why the disrespect of my time around here has gotten
intolerable.


> 
> 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
> 
>