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
