← Back to team overview

kicad-developers team mailing list archive

Re: Environment variables patch.

 

On 1/27/2015 5:36 PM, Bernhard Stegmaier 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.

I meant the footprint, symbol, and 3D model libraries.

> 
>>> => 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)?

Linux packagers will set CMAKE_INSTALL_PREFIX according to the
requirement of their system so it will also work in this case.  The
windows NSIS installer will work as long as the default install path is
%PROGRAMFILES% and the user does not change it at install.  Most users
will use the default which my solution will cover.  I'm just trying to
come up with a sane default for OSX.

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

If the bundle paths are always absolute, my solution will never work for
OSX.  I guess the best solution is to hard code this path to the most
likely fully qualified path.  Please keep in mind that is the default
path which assuming the user does nothing custom is where the footprint,
symbol, and 3D libraries will be installed.  That is the intended goal.
 It will always work (at least on Windows and Linux) if the user
installs from a source build by running `make install`.

> 
> 
> Regards,
> Bernhard 
> 



References