← Back to team overview

kicad-developers team mailing list archive

Re: PATCH: Setting OS X KISYSMOD value in bundle

 

On 1/8/2015 10:40 AM, Adam Wolf wrote:
> Hi Wayne,
> 
> Thank you for wearing all those hats!  It makes you a pleasure to work with.

Your welcome.  That's what makes working on KiCad challenging.  I am a
user, developer, and packager trying to satisfy all of those
requirements on three separate platforms each with their own set of ever
changing quirks.  I'm not sure anyone can fully wrap their head around
all of it.  I know I can't.

> 
> I am not familiar with the path dialog work.  From what I can infer, it
> sounds great--even better than default environment variable values is
> something users can see and modify without restarting Kicad.

This work is aimed squarely at the user.  The current design resolved an
ongoing library issue but created a headache for the user in that it
introduced the concept of environment variables.  The goal with the path
dialog is to come up with default settings that work in most cases and
shield the user from having to learn how to set environment variables.
Once this work is complete, there should be no reason for user's to set
environment variables at the system level unless they have specific
configuration requirements.

> 
> If we have a solid plan going forward for this, I feel even better about
> putting a custom patch for the environment variable in the mac
> nightlies, in the interest of serving users and not delaying the
> nightlies release any sooner. As soon as the path dialog stuff is ready,
> we can pull the custom patch and provide a transition for users if
> needed.  (I don't expect there would be...)

Setting the environment variable on OSX may or may not be desirable
depending on the user's preferences.  Please note that once an
environment variable is set at the system or user level, the new code
will ignore the user's KiCad setting.

> 
> Currently, any custom patches are listed in the README automatically.
> 
> I would not feel as good about putting custom patches in for the
> upcoming stable release.
> 
> Bernhard, folks, what do you think?  Is this a reasonable option?
> 
> Adam Wolf
> 
> Cofounder and Engineer
> 
> W&L
> 
> On Jan 8, 2015 9:15 AM, "Wayne Stambaugh" <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 1/8/2015 9:43 AM, Adam Wolf wrote:
>     > Hi Wayne,
>     >
>     > When dealing with Kicad's internals, I often have the perspective of a
>     > packager, and sometimes that makes me have weird ideas.
> 
>     As a developer, packager, and user I have the same issues.  What is good
>     for development purposes is not always the best for packaging or use and
>     vice-versa.  Finding a good balance is more difficult than one would
>     think.
> 
>     >
>     > I remember the search path discussions and the issues where it was
>     > impossible to tell which footprint got picked.  I don't want to bring
>     > that back.
>     >
>     > Right now, KISYS3DMOD has a default value defined in code if the
>     > environment variable isn't set.  What about if there is a default
>     value
>     > for all of the standard environment variables?
>     >
>     > I'm not sure what everyone else thinks, but defining those default
>     > values in CMake might actually be a good idea--then packagers can
>     modify
>     > them without patching, but it wouldn't be a problem either if we just
>     > split it up into Lin/Win/OSX sections in the code.
> 
>     I plan on setting the default paths and environment variables as part of
>     the path dialog work.  I will most likely use the paths generated by
>     CMake as the defaults.  This should work in most cases and will work in
>     every case when `cmake install` is used to install kicad.  The only
>     place I see an issue is the windows installer.  By default cmake sets
>     the install path on windows to c:\Program Files\kicad or c:\Program
>     Files (x86)\kicad.  If the user chooses to change the install path, the
>     default path settings would be wrong.  There are several ways around
>     this that are very windows specific and each having it's own set of
>     issues.
> 
>     >
>     > Adam Wolf
>     > Cofounder and Engineer
>     > W&L
>     >
>     > On Thu, Jan 8, 2015 at 7:44 AM, Wayne Stambaugh
>     <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>     > <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>> wrote:
>     >
>     >     Fully defined paths can be used in the fp-lib-table if that is
>     your
>     >     preference.  Environment variable substitution is optional. 
>     You are
>     >     free to use any environment variable you want.  KISYSMOD is
>     merely the
>     >     variable name used for the default footprint library path.  I use
>     >     KILCLMOD to point to the path of my custom footprint
>     libraries.  I set
>     >     these paths to the same disk partition and and path in both
>     windows and
>     >     linux so I'm always using the same footprint libraries when I'm
>     >     developing on either platform.
>     >
>     >     On 1/8/2015 8:33 AM, Adam Wolf wrote:
>     >     > Maybe.  For KISYSMOD, I am not sure if it is used anywhere
>     in the source.
>     >     >
>     >     > I do not think your work around would work for KISYS3DMOD,
>     though.
>     >     >
>     >     > On Jan 8, 2015 7:29 AM, "Miguel Ángel Ajo"
>     <majopela@xxxxxxxxxx <mailto:majopela@xxxxxxxxxx>
>     <mailto:majopela@xxxxxxxxxx <mailto:majopela@xxxxxxxxxx>>
>     >     > <mailto:majopela@xxxxxxxxxx <mailto:majopela@xxxxxxxxxx>
>     <mailto:majopela@xxxxxxxxxx <mailto:majopela@xxxxxxxxxx>>>> wrote:
>     >     >
>     >     >     Can’t users just change that reference to their own path
>     on their
>     >     >     own fp-lib-table
>     >     >     instead of the ENV var reference if they don’t want the
>     system modules?
>     >     >
>     >     >     That would be reasonable enough to me.
>     >     >
>     >     >
>     >     >
>     >     >     Miguel Ángel Ajo
>     >     >
>     >     >     On Thursday, 8 de January de 2015 at 13:53, Adam Wolf wrote:
>     >     >
>     >     >>     I hear what you're saying.
>     >     >>
>     >     >>     I don't really like the idea of using environment
>     variables to
>     >     >>     drive the behavior of GUI programs, especially in OS
>     X.  They're
>     >     >>     tricky in OS X, and they're hard to explain to a lot of
>     users.
>     >     >>
>     >     >>     Fixing this through changing the behavior of how
>     KISYSMOD and
>     >     >>     probably the other environment variables work in Kicad
>     is probably
>     >     >>     a fair bit of work, at least a week or two--when you
>     include
>     >     >>     developer discussion, regression testing on other
>     platforms, stuff
>     >     >>     like that, probably even longer.
>     >     >>
>     >     >>     I'm not 100% happy about it, but would something like
>     this be an
>     >     >>     OK stopgap measure while we figure out the right thing
>     moving
>     >     >>     forward?  I am fine only putting this patch in my builds.
>     >     >>
>     >     >>     Adam Wolf
>     >     >>     Cofounder and Engineer
>     >     >>     Wayne and Layne
>     >     >>
>     >     >>     On Jan 8, 2015 6:26 AM, "Bernhard Stegmaier"
>     >     >>     <stegmaier@xxxxxxxxxxxxx
>     <mailto:stegmaier@xxxxxxxxxxxxx> <mailto:stegmaier@xxxxxxxxxxxxx
>     <mailto:stegmaier@xxxxxxxxxxxxx>>
>     >     <mailto:stegmaier@xxxxxxxxxxxxx
>     <mailto:stegmaier@xxxxxxxxxxxxx> <mailto:stegmaier@xxxxxxxxxxxxx
>     <mailto:stegmaier@xxxxxxxxxxxxx>>>>
>     >     wrote:
>     >     >>>     __
>     >     >>>
>     >     >>>     Hi Adam, hi all,
>     >     >>>
>     >     >>>     that IMHO could be problematic (depends on what you intend
>     >     to have).
>     >     >>>
>     >     >>>     For a single-user environment this might be OK, but it
>     then
>     >     >>>     forces modules to be in a machine specific folder
>     common to all
>     >     >>>     users. In a multi-user environment you probably might not
>     >     want to
>     >     >>>     have that. And, I never read somewhere that you can
>     override
>     >     this
>     >     >>>     setting of the bundle somehow, so this could be a once
>     and for
>     >     >>>     all decision (as long as you don't fiddle around with the
>     >     >>>     Info.plist) and you wouldn't need an environment
>     variable at
>     >     all...
>     >     >>>     Further, I think I tried once to use "~" or "$HOME" in
>     >     Info.plist
>     >     >>>     but it doesn't expand such variables. So, you obviously
>     >     can't set
>     >     >>>     the path to something in user home with this method.
>     >     >>>     Last, I don't know if always any (non-root) user is
>     allowed to
>     >     >>>     write into /Library/Application Support/kicad?
>     >     >>>
>     >     >>>     In my opinion, the old concept of search paths did fit
>     such
>     >     >>>     hardcoded paths much better than it is currently with
>     >     environment
>     >     >>>     variables. If environment variables are too hard to
>     set, then
>     >     >>>     probably a configuration setting directly from some
>     "Settings"
>     >     >>>     menu would be better.
>     >     >>>
>     >     >>>     My opionion: I wouldn't want to have it that way, but
>     since I am
>     >     >>>     the only one using KiCad on my machines I can also
>     live with
>     >     some
>     >     >>>     links pushing things into the spot I want to have it.
>     >     >>>
>     >     >>>     This altogether is somewhat inconsistent, because
>     eeschema will
>     >     >>>     *always* look in <base>/library with <base> being (in that
>     >     order):
>     >     >>>     * $KICAD
>     >     >>>     * ~/Library/Application Support
>     >     >>>     * /Library/Application Support
>     >     >>>     * <kicad.app>/Contents/SharedSupport
>     >     >>>
>     >     >>>     So, if the path should be fixed for pcbnew, I would at
>     least
>     >     >>>     expect eeschema to behave the same way (i.e., removing
>     all the
>     >     >>>     other paths and also pointing it to the one global
>     >     >>>     /Library/Application/Support/kicad/library).
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>     Regards,
>     >     >>>     Bernhard
>     >     >>>
>     >     >>>     PS:
>     >     >>>
>     >     >>>     I just had a brief look at the Apple docs and did see here
>     >     >>>
>     >     >>>
>     >     
>     https://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/20001431-106825
>     >     >>>
>     >     >>>     that obviously the environment set in the Info-plist
>     is only
>     >     >>>     valid when launching via an icon, but not via
>     command-line:
>     >     >>>     <<<
>     >     >>>     These environment variables are set only for apps launched
>     >     >>>     through Launch Services. If you run your executable
>     directly
>     >     from
>     >     >>>     the command line, these environment variables are not set.
>     >     >>>     >>>
>     >     >>>
>     >     >>>     So, another issue that already now with the KIGITHUB
>     variable
>     >     >>>     might lead to confusion...
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>     On 2015-01-08 06:52, Adam Wolf wrote:
>     >     >>>
>     >     >>>>     Hi folks,
>     >     >>>>
>     >     >>>>     As you may know, it's harder than it seems to set an
>     >     environment
>     >     >>>>     variable on a bundle in OS X as a user.
>     >     >>>>
>     >     >>>>     I have a patch here for the OS X bundle that sets
>     KISYSMOD to
>     >     >>>>     /Library/Application Support/kicad/modules
>     >     >>>>
>     >     >>>>     Please let me know if there are any questions or
>     comments.
>     >     >>>>
>     >     >>>>     Thanks!
>     >     >>>>
>     >     >>>>     Adam Wolf
>     >     >>>>     Cofounder and Engineer
>     >     >>>>     W&L
>     >     >>>>
>     >     >>>>     _______________________________________________
>     >     >>>>     Mailing list: https://launchpad.net/~kicad-developers
>     >     >>>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >     >>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >     >>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 



References