kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

I think Bernhard is on track here.

Reiterating, for OS X, for us, for now, /usr/local/share is
/Library/Application Support/

This isn't perfect, and there's reason to change it, maybe, but it's some
place the OS X devs and vocal users on the dev list mostly agree on :)

When I have been working on the footprints .dmg for users, I have been
tripped up by this time and time again.  I am not sure if the paradigm in
the kicad-library CMake works for OS X, but then again, I am ok with it
not.  On OS X, the idea is that the bundles are relocatable, and we don't
really support that for Windows and Linux, so in a lot of ways I'm ok
saying "OS X is special here"--as long as it doesn't make maintenance a
huge pain.

Thanks folks!

Adam Wolf

On Tue, Jan 27, 2015 at 4:36 PM, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx
> wrote:

>
> On 27.01.2015, at 21:20, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> > On 1/27/2015 2:57 PM, Bernhard Stegmaier wrote:
> >>
> >> CMAKE_INSTALL_PREFIX is of course defined when building on OS X, it is
> the folder where the app bundle will be stored.
> >
> > Is this not the path where the libraries are installed?  By default
> > CMAKE_INSTALL_PREFIX is set to the correct platform dependent path.
> > When building KiCad, you should always set CMAKE_INSTALL_PREFIX if the
> > default path is not where you want KiCad installed.
>
> The thing is, for libraries (you mean .so?) you don’t have absolute paths,
> but only those relative to the bundle.
> The install folder is, e.g., /my/build/folder/kicad.app/…
> Everything inside the bundle is linked relative to kicad.app, so you can
> move the bundle everywhere.
> The notion of a “install prefix” or where you “install” the bundle at
> build time doesn’t mean anything with bundles - it’s just a path you use at
> that moment in time, but maybe never again.
>
> >> => None of these paths will normally be used for CMAKE_INSTALL_PREFIX,
> so above #define will be way off.
> >> In general, I think this problem will also arise on Linux/Windows when
> not installing to the real target folder (like / or /usr/local)?
> >
> > If I'm following the current OSX install path logic, this statement in
> > the main CMakeLists.txt file:
> >
> >    set( KICAD_DATA ${OSX_BUNDLE_INSTALL_DIR}/${OSX_BUNDLE_SUP_DIR}
> >        CACHE PATH "Location of KiCad data files." FORCE )
> >
> > does not use CMAKE_INSTALL_PREFIX as the base path for the install
> > location of the data files.  It is the full install path.  I could add:
>
> Sure, but if I just pick to install the app bundle to /my/build/folder
> (because this is my preferred folder to build in), then this has nothing to
> do with the place where the modules/footprints/etc. are stored (e.g.,
> /Library/Application Support/kicad as one possible equivalent to
> /usr/local/share/kicad).
>
> > #if defined( APPLE )
> > #define KICAD_DATA_PATH "@KICAD_DATA@"
> > #else
> > #define KICAD_DATA_PATH "@CMAKE_INSTALL_PREFIX@/@KICAD_DATA@"
> > #endif
>
> Sure, you could also do the switch here using #ifdefs.
>
> > That should resolve the issue shouldn't it or am I missing something
> > else about how OSX bundles work?  If the above does work, then we really
> > should fix the OSX bundle install paths to use CMAKE_INSTALL_PREFIX as
> > the default base path so my original solution would work in all cases.
>
> Not quite for two reasons:
> (1) KICAD_DATA points to the data location *inside* the bundle used for
> everything that is put *into* the bundle at build time. You don’t want to
> use that for modules/footprints/etc. because this folder won’t be seen for
> or changed by normal users (it is inside the bundle which is normally
> hidden).
> (2) KICAD_DATA is the absolute path to where you have built the bundle -
> which is, as explained above, completely irrelevant. For OS X the
> equivalent of /usr/local/share is just /Library/Application Support (more
> or less, I might be wrong). This won’t change regardless of where the
> bundle is or the bundle has been built.
>
>
> Regards,
> Bernhard
>
>
> _______________________________________________
> 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
>