kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Hi folks,

>From a packaging perspective, and the perspective of getting this good code
Wayne wrote in  the codebase, I say let's go with
GetOSXKicadMachineDataDir().  It matches the rest of the OS X work Bernhard
and I and everyone else have been doing for months and months.

All these search paths are changeable, so they do not have to fit every
developer's niche need.

Please keep in mind: we are trying to establish defaults for non-developer,
non-expert users while allowing more skilled users and developers the
ability to change the defaults to fit their needs.

This is what Wayne's work is helping, and what we really have to keep in
mind as we march to the next stable release.

Adam Wolf
Cofounder and Engineer
W&L


On Wed, Jan 28, 2015 at 8:40 AM, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx
> wrote:

> OK... then, for now just simply setting the base to a fixed/hardcoded
>   /Library/Application Support/kicad
> will probably do the trick for OSX and at least should be consistent to
> what we have at the moment spread over various spots in the code.
> You could do that without any CMake magic directly in the code, maybe
> using GetOSXKicadMachineDataDir() from common.cpp if you don't want to
> hardcode the path once more.
>
>
> Regards,
> Bernhard
>
>
> On 2015-01-28 14:30, Wayne Stambaugh wrote:
>
>> On 1/28/2015 2:07 AM, Bernhard Stegmaier wrote:
>>
>>> Again, I am open for all reasonable suggestions for the path itself,
>>> this is not the discussion here.
>>>
>>
>> Correct.  We've turned this discussion into way more than I had
>> intended.  The discussion should be what is the best *default* path
>> (most commonly used path) on OSX that will work with a default install.
>>  Most users tend to stick with the defaults so my patch should cover
>> most use cases.  Power users should be clever enough to configure their
>> systems accordingly if they do not use the default install paths.  Once
>> we've established the best default path for OSX, I will commit the
>> revised patch and start working on the path editor dialog which will
>> allow users to change these local environment variables.  This way
>> environment variables will not have to be set system wide if that is the
>> user's preference.
>>
>>
>>> The only thing I want to say is that the install prefix concept in my
>>> opinion is just a unix thing which comes from compiling applications
>>> yourself… so, in my opinion you could say Linux is the odd guy here and you
>>> currently only mimic Unix in Windows… :)
>>>
>>> On Windows and OSX the install path of a binary at runtime or build time
>>> has nothing to do with data paths on the target user system.
>>> It may be the same for users (of e.g., homebrew and MacPorts) compiling
>>> their own version directly into the target place, but it is not true for
>>> all others using some pre-built stock packages.
>>>
>>> I guess the install path Wayne uses in his build robot won’t even exist
>>> on any user machine the package will be installed on.
>>>
>>
>> I don't install from packages.  I always install from my build tree by
>> running `make install` so this patch always works in my use case but I
>> am the exception to the rule.  Users will most likely be using some type
>> of package installer.
>>
>>
>>> And IMHO it’s the same for Windows - you will build somewhere but not
>>> c:\Program FIles, the installer will grab it from there to build the
>>> install package, the user again installs it wherever he/she likes. No more
>>> install prefix from build time visible on user side...
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 28.01.2015, at 05:57, Bob Gustafson <bobgus@xxxxxxx> wrote:
>>>
>>>  I would vote for a location that keeps KiCad things 'together' in the
>>>> hope that everything could be on a flash drive which could be runable when
>>>> it is plugged into a Mac - which has appropriate homebrew and generic
>>>> applications and libraries. There does need to be a decision about what is
>>>> unique to KiCad (on flash drive) and what is 'everything else'.
>>>>
>>>> It seems that /Library, ~/Library, and ~/Documents would require things
>>>> to be copied off of a flash drive whereas @CMAKE_INSTALL_PREFIX - might be
>>>> on the flash drive.
>>>>
>>>> If you don't have a flash drive, or don't want to use a flash drive,
>>>> KiCad doesn't have to be on a flash drive - it could be totally within a
>>>> directory/folder somewhere on the hard disk.  If everything was within that
>>>> directory it would be good.
>>>>
>>>> Bob G
>>>>
>>>> On 01/27/2015 01:57 PM, Bernhard Stegmaier wrote:
>>>>
>>>>> Hi Wayne,
>>>>>
>>>>> I had a look at the patch and I currently see a small issue on OS X
>>>>> (maybe not only being OS X specific…).
>>>>>
>>>>> The definition of the data path is as follows in config.h.make:
>>>>>    /// The install prefex used for KiCad's libraries.
>>>>>    #define KICAD_DATA_PATH                 "@CMAKE_INSTALL_PREFIX@/@
>>>>> KICAD_DATA@"
>>>>>
>>>>> CMAKE_INSTALL_PREFIX is of course defined when building on OS X, it is
>>>>> the folder where the app bundle will be stored.
>>>>>
>>>>> I know there recently was a discussion on the list on where to place
>>>>> what on OS X.
>>>>> I don’t want to start this again, some of the mentioned possibilities
>>>>> for a default path on OS X could be
>>>>> * /Library/Application Support/kicad/…
>>>>> * ~/Library/Application Support/kicad/…
>>>>> * ~/Documents/kicad/…
>>>>> => 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)?
>>>>>
>>>>> That should be easy to solve by either using some @KICAD_DATA_BASE@
>>>>> instead of @CMAKE_INSTALL_PREFIX@, which can be set in the various
>>>>> platform dependent if’s in CMakeLists.txt to the desired base.
>>>>> Or, just don’t use any combination of variables in config.h.cmake, but
>>>>> just a single one set correctly in CMakeLists.txt.
>>>>>
>>>>> Apart from that I don’t see anything that should brake something on OS
>>>>> X.
>>>>> The only thing to add is that as soon as the patch made it in, we can
>>>>> again remove setting KIGITHUB from Info.plist.
>>>>>
>>>>> If you change your patch, I can make the OS X relevant modifications,
>>>>> test them, and send a patch back to you.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Bernhard
>>>>>
>>>>>
>>>>>  On 25.01.2015, at 23:33, Wayne Stambaugh <stambaughw@xxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>> No hurry Bernhard.  Whenever you get a chance.  I just want to have a
>>>>>> complete solution before I commit the changes.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>> On 1/25/2015 2:22 PM, Bernhard Stegmaier wrote:
>>>>>>
>>>>>>> Hi Wayne,
>>>>>>>
>>>>>>> I’ll try to look at it starting tomorrow, so I hope I can give
>>>>>>> feedback
>>>>>>> until mid of the week.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bernhard
>>>>>>>
>>>>>>> On 25.01.2015, at 20:02, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>>>
>>>>>>>  On 1/25/2015 10:29 AM, Nick Østergaard wrote:
>>>>>>>>
>>>>>>>>> 2015-01-23 14:42 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>>>>>> <mailto:stambaughw@xxxxxxxxx>>:
>>>>>>>>>
>>>>>>>>>> As you all know, we have had many users struggle with setting up
>>>>>>>>>> the
>>>>>>>>>> environment variables used in the footprint library table and 3D
>>>>>>>>>> model
>>>>>>>>>> code.  The attached patch sets the process environment variables
>>>>>>>>>> KIGITHUB and KISYS3DMOD.  KIGITHUB should work for all platforms
>>>>>>>>>> since
>>>>>>>>>> it is the URL for the kicad library repos on GitHub which is
>>>>>>>>>> always
>>>>>>>>>> https://github.com/KiCad.  KISYS3DMOD uses the 3D model library
>>>>>>>>>> install
>>>>>>>>>> path created during the CMake configuration.  This works fine for
>>>>>>>>>> me on
>>>>>>>>>> windows and linux.  OSX may be a different story due to the way
>>>>>>>>>> the
>>>>>>>>>> bundle paths are defined.  Would on of the OSX devs please test
>>>>>>>>>> this and
>>>>>>>>>> give me some feedback?  Please don't forget to remove these
>>>>>>>>>> environment
>>>>>>>>>> variables that are set elsewhere.  Otherwise, the environment
>>>>>>>>>> variable
>>>>>>>>>> in this patch will be ignored.  My guess is that if we get the
>>>>>>>>>> default
>>>>>>>>>> environment variable set correctly that it would solve the
>>>>>>>>>> problem for
>>>>>>>>>> the largest percentage of users until I get some time to work on
>>>>>>>>>> the
>>>>>>>>>> dialog to edit them.  I will also add KISYSMOD to this code once
>>>>>>>>>> have
>>>>>>>>>> the default OSX paths established.
>>>>>>>>>>
>>>>>>>>> What would the default KISYSMOD be? I currently set it to
>>>>>>>>> /usr/share/kicad/footprints in my kicad-pretty-git AUR package [1].
>>>>>>>>>
>>>>>>>>> [1] https://aur.archlinux.org/packages/kicad-pretty-git/
>>>>>>>>>
>>>>>>>>>  The default KISYSMOD on Linux would be
>>>>>>>> /usr/local/share/kicad/footprints.  However, this can be changed
>>>>>>>> during
>>>>>>>> the CMake configuration by passing -DCMAKE_INSTALL_PREFIX=/
>>>>>>>> install/path.
>>>>>>>> My guess is that packagers set this to /usr instead of the default
>>>>>>>> /usr/local when building distro specific KiCad packages.  The
>>>>>>>> default
>>>>>>>> should always correctly point to the correct path as long a the
>>>>>>>> library
>>>>>>>> install path is also set to the same path as the source build
>>>>>>>> install
>>>>>>>> path.  The problem child is OSX because of the way the install
>>>>>>>> paths are
>>>>>>>> defined so I still need an answer from the OSX devs before I commit
>>>>>>>> this
>>>>>>>> patch.  The Windows NSIS installer can also be problematic if the
>>>>>>>> user
>>>>>>>> installs KiCad anywhere but the default path which is c:\Program
>>>>>>>> Files.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
>