Hi Wayne, When dealing with Kicad's internals, I often have the perspective of a packager, and sometimes that makes me have weird ideas.
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. Adam Wolf Cofounder and Engineer W&L On Thu, Jan 8, 2015 at 7:44 AM, Wayne Stambaugh <stambau...@gmail.com> 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" <majop...@redhat.com > > <mailto:majop...@redhat.com>> 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" > >> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> 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@lists.launchpad.net <mailto: > kicad-developers@lists.launchpad.net> > >>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>> More help : https://help.launchpad.net/ListHelp > >>> > >>> _______________________________________________ > >>> Mailing list: https://launchpad.net/~kicad-developers > >>> Post to : kicad-developers@lists.launchpad.net > >>> <mailto:kicad-developers@lists.launchpad.net> > >>> Unsubscribe : https://launchpad.net/~kicad-developers > >>> More help : https://help.launchpad.net/ListHelp > >>> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : kicad-developers@lists.launchpad.net > >> <mailto:kicad-developers@lists.launchpad.net> > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
