kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

On 27/apr/2014, at 23:36, 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?

Uh i’m sorry that I misunderstand, i’vent understand that was a private dialog about OSX proceedings.
UI Binaries in OSX are distributed only in the bundles, the rest are only an intermediate files used for the build, like object files.


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

Each binary is a single application, each application is hosted in a bundle, each bundle is a single ICON.
This is the OS architecture.
There aren’t 3 copies, who says that hasn’t understood well what happens.


As you can see in the later message i’ve followed your idea, i’ve bent the system to symbolic link the kifaces.
I’ve worked 3 months to make a build system that support your kiface interface, that was blueprinted and acted without screening the work impact on the OSX and the work needed to make it work, I’m still supporting it as you have seen letting work again the USELESS OSX in few hours from my involvement.
I’ve supported and i’m still supporting your project: I don’t call this kind of behavior disrespectful, i’ve spent 3 months to support your blueprint. 

I appreciate that you are now supporting also privately and in active manner the OSX users, I think we could spend better our efforts trying to coordinate us: filing a bug report and sollecitate an involvement/coordination with who is caring that side of Kicad could help to increase our product/effort ratio.

I’m so disrespectfully that i wish to assets it with you there:
macbook:product marco$ find . -name "*.kiface"
./cvpcb/_cvpcb.kiface
./cvpcb/cvpcb.app/Contents/MacOS/_cvpcb.kiface
./eeschema/_eeschema.kiface
./eeschema/eeschema.app/Contents/MacOS/_eeschema.kiface
./gerbview/_gerbview.kiface
./gerbview/gerbview.app/Contents/MacOS/_gerbview.kiface
./kicad/kicad.app/Contents/MacOS/_cvpcb.kiface
./kicad/kicad.app/Contents/MacOS/_eeschema.kiface
./kicad/kicad.app/Contents/MacOS/_pcbnew.kiface
./pagelayout_editor/_pl_editor.kiface
./pagelayout_editor/pl_editor.app/Contents/MacOS/_pl_editor.kiface
./pcb_calculator/_pcb_calculator.kiface
./pcb_calculator/pcb_calculator.app/Contents/MacOS/_pcb_calculator.kiface
./pcbnew/_pcbnew.kiface
./pcbnew/pcbnew.app/Contents/MacOS/_pcbnew.kiface

Describing that:
./cvpcb/_cvpcb.kiface <— build intermediate file (not distributed like .o files)
./cvpcb/cvpcb.app/Contents/MacOS/_cvpcb.kiface <— distributed (is inside the .app)

Only what is under the *.app is the bundle and is what is distributed to the users.

Now to show what i said in your respectfully mail thread "BZR 4813 OS X crash all the time - USELESS” that was kept private on which probably for my fault i’ve missed any kind of direct involvement.

macbook:kicad marco$ ls -alrt kicad.app/Contents/MacOS/*.kiface
lrwxr-xr-x  1 marco  staff  49 27 Apr 16:27 kicad.app/Contents/MacOS/_pcbnew.kiface -> ../../../pcbnew.app/Contents/MacOS/_pcbnew.kiface
lrwxr-xr-x  1 marco  staff  53 27 Apr 16:27 kicad.app/Contents/MacOS/_eeschema.kiface -> ../../../eeschema.app/Contents/MacOS/_eeschema.kiface
lrwxr-xr-x  1 marco  staff  47 27 Apr 16:27 kicad.app/Contents/MacOS/_cvpcb.kiface -> ../../../cvpcb.app/Contents/MacOS/_cvpcb.kiface

As you can see from the first letter those are symbolic links to the respective .kiface as you suggested and declared in the same thread

So there are NOT 3 times the same file on OSX users Mac as stated.

With the usual wish to make cleaver things,

—
Marco