kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

Jean-Paul,
Ok, i try to re-state: you weren't supposed to do a make install, just copy
the binaries/bundle in place.
On OSX all what you need have be inside the bundles, is how the system work
and users expect, since there is no need for /usr/share or other things
there is need to issue a make install, is enough copy the .app where you
want (Installation Directory; DMG; or any other distributing package).
All what is outside kicad.app, eeschema.app, etc are not to be distribuited
(so no 3 releases of files).

The issue with kicad.app has started with release
4807<http://bazaar.launchpad.net/%7Ekicad-product-committers/kicad/product/revision/4807>(10
days ago) when was kifaced (previous was not).
There is no radical departure from apple concept of bundle, the issue was
how to make symbolic link from eeschema.app from the building tree that
still valid also when deployed in the final destination.

There can be several approaches for the symbolic link:
Use an absolute path like
/Application/Kicad/eeschema.app/[...]/eeschema.kiface, that restrict where
to place the binaries: will create more problems than the one he fix, users
on OSX has not a fixed path where to place binaries/bundles there is the
high risk that those will point to nowhere, moreover borns an issues for
developers: they have to install the application to debug or develop.
Develop an application doing an install each time will be really time
consuming and not pratical at all.

Relative path:
The use of the relative link is fine and is what i've used: the issue here
is 1 level of difference between the repository where you build and install
place, where all the bundle/binaries are at the same level.

$REPOSITORY/eeschema/eeschema.app
$REPOSITORY/kicad/kicad.app

Versus

$INSTALLDIR/eeschema.app
$INSTALLDIR/kicad.app

That means that the number of ".." will be different in relative symbolic
link.

I've solved this doing symbolic links in the $REPOSITOR/kicad/ to
applications making it as they were installed, then link them, moreover
this solution makes the developer also be able to test the application
buttons in place.

After applications link you will find

$REPOSITORY/kicad/kicad.app
$REPOSITORY/kicad/eeschema.app -> ../eeschema/eeschema.app

Then you are able to do the right symbolik link.

Regarding the distribution, i can assure that since 2009 binaries could be
shipped in a single dmg, .zip, .tar.gz.
I can also assure you that there are a much more packagers than developers
on OSX, if they find difficult do a copy instead a 'make install' to ease
the developer work and let they work better they will be much more
frustrated soon.

Bye,

--
Marco


On Tue, Apr 29, 2014 at 3:01 AM, Jean-Paul Louis <louijp@xxxxxxxxx> wrote:

> Marco,
>
> It looks like the previous problem has been fixed, and I am now able to
> complete the build.
> I just finished to build the BZR4837 without trouble.
> I understand what you said about the install. but the cake process is not
> working right.
> During the "make install", a “bin" directory is added to the default
> install directory.
> The apps should be in /Applications/Kicad/, but the "make install” put
> them in
> /Applications/Kicad/bin/. That’s why I said that the install process is
> broken.
> I made cmake use "/Applications/Kicad" by adding the switch
>  -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR to cmake and I add previously set
> INSTALL_DIR to /Applications/Kicad in my script.
> So the part of cmake that needs to be fixed is the area where the /bin is
> added to the install path.
> It is ok to have for UNIX, but not for APPLE. Then, at the end,  we need
> to fix the kicad bundle.
> Symbolic links is one way to fix the kiface issue with an Apple bundle. I
> also understand that
> kiface concept is a radical departure from the Apple concept of bundle,
> but Dick idea of the symlinks
> worked nicely when I tested it. I need to consolidate all the experiments
> that we did into a single document
> explaining how to fix the broken process until we can fix the cmake for
> kicad on OS X.
>
> I am willing to help testing the OS X builds until we can make a package
> (DMG) for easy distribution.
> Then we might get more leverage as OS X users if more people use Kicad on
> OS X.
> A lot of people using Mac OS X are frustrated because they do not find a
> decent version of Kicad.
> So they go use other CAD software like Eagle, GEDA, and many others that
> are nowhere near the performance
> of Kicad.
>
> Jean-Paul
>
>
> On Apr 28, 2014, at 4:46 PM, Marco Serantoni <marco.serantoni@xxxxxxxxx>
> wrote:
>
>
> On 28/apr/2014, at 19:25, Jean-Paul Louis <louijp@xxxxxxxxx> wrote:
>
> Jean-Paul,
> You should try bzr 4835, look to ML “OSX - Issue with the last Compiler
> Update”, as you see is not always simple to keep up the ML.
> I’ve waited you on IRC until 1am Local time, then i’m an Human i need
> sleeptime too.
>
> You weren’t supposed to use install as i said to you in the mails you have
> to just copy the only bundles in place, in the case zip/package them for
> further distribution.
> I’ve also suggested to you to use cp.
>
> If you want to shortcut exec from the repository build root:
> mkdir -p /Applications/Kicad
> cp -R ./bitmap2component/bitmap2component.app /Applications/Kicad
> cp -R ./cvpcb/cvpcb.app /Applications/Kicad
> cp -R ./eeschema/eeschema.app /Applications/Kicad
> cp -R ./gerbview/gerbview.app /Applications/Kicad
> cp -R ./kicad/kicad.app /Applications/Kicad
> cp -R ./pagelayout_editor/pl_editor.app /Applications/Kicad
> cp -R ./pcb_calculator/pcb_calculator.app /Applications/Kicad
> cp -R ./pcbnew/pcbnew.app /Applications/Kicad
>
> Bye,
> —
> Marco
>
> Marco,
>
> I have been working on the Mac OS X build for quite a while now, and I was
> successful in the build.
> The weak part was the install, as the default install was installing the
> bundles in /usr/local/bin which is wrong for Apple OS X.
> So I added a “-DCMAKE_INSTALL_PREFIX=$INSTALL_DIR” in my script with
> INSTALL_DIR=/Applications/KiCad.
> The Cmake was still wrong because the bundles were installed in
> "/Applications/KiCad/bin” instead of “/Applications/KiCad”.
> Adam Wolf helped me to have the script running as it is described in the
> file you mentioned in your previous email.
> I succeeded the first time February 27th, and I posted an email here, so
> you can find it in the ML archive.
> On March 13th, you told me to connect on IRC. I went there, and waited for
> hours without anyone ever talking. I only saw a bunch of users all asleep,
> maybe that was because of the time difference between USA and Europe.
> We had several emails between you, Adam and me around from March 21st to
> March 26th, so I progressed in my build. That is the period when Dick
> started to help me.
>
> I modified my script to move the files to the right place, and that was
> not good enough. That’s when Dick helped me a lot to understand what was
> wrong. I posted all the steps in this mailing list, so you should have been
> made aware of the issues
> few weeks ago.
>
> As of today, the OS X build (BZR4830) is broken again.
> *                 ^*
> 174 warnings and 2 errors generated.
> make[2]: *** [pcbnew/router/CMakeFiles/pnsrouter.dir/pns_router.cpp.o]
> Error 1
> make[1]: *** [pcbnew/router/CMakeFiles/pnsrouter.dir/all] Error 2
> make: *** [all] Error 2
> Mon Apr 28 12:30:08 EDT 2014
>
> Building KiCad for OS X took 0:17:09.
>
> jean-pauls-mbp:Soft_Dev jean-paullouis$ cat
> ~/Soft_Dev/kicad-build/version.h | grep BZR
> #define KICAD_BUILD_VERSION "(2014-04-25 BZR 4830)"
> jean-pauls-mbp:Soft_Dev jean-paullouis$
>
> Will you help to fix this?
>
> Jean-Paul
>
>
>
>
> On Apr 28, 2014, at 8:26 AM, Marco Serantoni <marco.serantoni@xxxxxxxxx>
> wrote:
>
> realized
>
>
>
>
>