kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

Jean-Paul,
I've well realized that there are problems to build Kicad on OSX, i've
worked a lot since 2008 to let it work as it does now including a lot of
patches needed to make it work.
The documentation on how to compile Kicad is in
Documentation/compiling/mac-osx.txt, do you have tried following that ?
Why you doesn't contacted me that mantain OSX ?

KicadOSXBuilder is not a my product and i can't help you a lot with him,
I've aided Miguel Angel in the past to do it, then to respond to other OSX
users and the mounting request for the Kiface interface, i had to integrate
all the changes in the Cmake Building system to make the compiling more
flexible and portable (dynamic libraries,  compiled for kicad  and for the
choosen Architecture) avoiding request to installl external
libraries/packages .

The only thing you have to do is Copy all the .app to the distribution
package, all the rest you see are only intermediate files.

About the three copies of kiface as i was able to explain in a previous
mail there aren't tree and are not intended to be distributed.


--
Marco


On Mon, Apr 28, 2014 at 4:37 AM, Jean-Paul Louis <louijp@xxxxxxxxx> wrote:

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