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 <[email protected]> wrote: > > On 27/apr/2014, at 23:36, 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. >> >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
