kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

Well, in fact I think it also isn’t really so much different on Windows.
Where would you put general data similar to /usr/share on linux there?
Maybe in the “My documents” folder of “All users” (or whatever it is called) - or maybe one of the other application data folders that Windows has (those normally being hidden).
This data folder is always the same regardless if you install your application in "\Program Files\foo” or in “\All My SW\foo”.
In that sense, the windows application is also relocatable - and nobody forces you to put generic data somewhere in the binary path, or?


Regards,
Bernhard

On 27.01.2015, at 23:41, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:

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