Le 28/01/2015 08:07, Bernhard Stegmaier a écrit :
Again, I am open for all reasonable suggestions for the path itself, this is not the discussion here.
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.
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
Looks like it is hard to define a suitable default value for these env vars.
And we are just talking about a very basic case: an user who installs
Kicad on his own computer.
There are other cases: installing Kicad and libs on a network (frequent
in schools, or when few guys are working together in a company, and
therefore have to share some libraries).
What about a config dialog which allows user to define the mandatory env
vars (and other personal env vars for advanced users), which are the
default paths for libs and 3d shapes?
It could be automatically open each time mandatory env vars (KISYSMOD,
KISYS3DMOD) are not yet defined, therefore the first time Kicad is run.
The other advantage of a config dialog, and therefore env vars stored in
a kicad config file is the fact we know they are kicad env vars, and
they can be listed in the fp table wizard.
In other words, they are env vars for Kicad code (and developers) but
just parameters (default paths) to define (like default texts and pad
sizes, or library list) for users.
They are env vars, but could be called paths nicknames for users (we do
that for fp libs in fp lib table.
