kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 1/27/2015 5:41 PM, Adam Wolf wrote:
> I think Bernhard is on track here.
> 
> Reiterating, for OS X, for us, for now, /usr/local/share is
> /Library/Application Support/ 

Is /Library/Application Support/ an absolute path.  If so, then that's
probably the correct default value for OSX.

> 
> 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 <mailto:stegmaier@xxxxxxxxxxxxx>> wrote:
> 
> 
>     On 27.01.2015, at 21:20, Wayne Stambaugh <stambaughw@xxxxxxxxx
>     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
>