kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

Hi Marco,

I am sorry that you didn’t realize that there was problems with the OS X builds.
I am trying to help, and to do so, I took the responsibility to build new BZR revs on OS X as often as possible for me.
I was struggling to build, so I posted questions on this Mailing list and on the kicad-user list.
I received help from various people, and finally I succeeded in my builds, but with quite a few gotchas left to resolve.
Dick is really the one who spent time with me, and together we improved the OS X process, but it seems that it is broken again. 
I am currently traveling to visit my family (new grand-son), so until may 10th, I will not have as much time as I used to in order to do a new OS X build several times a week as I was doing before.
I tried to use the KicadOSXBuilder script from github, but never reached the end of the script. It crashed on step 5.

So I decided to start from scratch. For OS X build, the Cmake is still badly broken, as the build will not complete as downloaded from the repository. So I created a Bash script to do some repairs of the process (thanks to Adam and Dick mostly).
As currently existing, the "make install” process is still broken because the OS X bundles end-up in a bin directory, which is not OS X standard behavior. Thanks to Dick help, I had a good build with a few symlinks to have only one copy of the kiface files.
This was until 4810 to 4817. I tried to build yesterday (I forgot the BZR number) with a fresh install to create a new baseline in order to test the patch from Dick, but I failed miserably, as I could not build anymore.
Tomorrow Monday, I will try to get some time to do a new build, and will report here my findings.
I am using the latest version of the tools (OS X 10.9.1 - Xcode 5.1 - Developer tools )
To clear the air about the 3 versions of kiface, we were looking at the result of the install in the /Applications/KiCad directory.
There was one copy of the kiface files in that directory with all the *.app bundles, and another one kiface file in each of the bundles.
That makes for two copies. Then in order to work, we needed a kiface for eeschema, cvpcb and pcbnew in the kicad bundle. That’s the third copy.
With Dick help, I deleted all the kiface files from the install directory (/Applications/KiCad), and added the 3 symlinks in the kicad bundle.
So I am saying that the Cmake process needs to be fixed in order to have a clean build under OS X, and also a clean install.
Then we will be able to create a distribution process for OS X users that cannot or do not want to build, but would like to use Kicad on OS X natively.

Jean-Paul

 
On Apr 27, 2014, at 8:25 PM, Marco Serantoni <marco.serantoni@xxxxxxxxx> wrote:

> 
> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp