On 6/17/2013 5:03 PM, Dick Hollenbeck wrote:
Solution B:
===========
// Path list for KiCad data files
static wxString s_KicadDataPathList[] = {
#ifdef __WINDOWS__
wxT( "c:/kicad/share/" ),
wxT( "d:/kicad/share/" ),
wxT( "c:/kicad/" ),
wxT( "d:/kicad/" ),
wxT( "c:/Program Files/kicad/share/" ),
wxT( "d:/Program Files/kicad/share/" ),
wxT( "c:/Program Files/kicad/" ),
wxT( "d:/Program Files/kicad/" ),
#else
wxT( "/usr/share/kicad/" ),
wxT( "/usr/local/share/kicad/" ),
wxT( "/usr/local/kicad/share/" ), // default data path for "universal
// tarballs" and build for a server
// (new)
wxT( "/usr/local/kicad/" ), // default data path for "universal
// tarballs" and build for a server
// (old)
#endif
wxT( "end_list" ) // End of list symbol, do not change
};
Scrap the above in gestfich.cpp.
Go instead to a CMake "datapath" variable, something like CMAKE_INSTALL_PREFIX,
but data
specific. (Must we always assume that application code and application data
are tied
together, please no.) And generate the correct path from from a cmakedefine in
config.h.in. Then simply hard code that path in your code now, rather than
guesstimating
it.
This will work when installing from source and probably work well for
developers. The downside to this is the NSIS windows installer allows
you to change the default install path to where ever the user chooses.
So hard coding the path will be problematic on Windows. The other
option is to have the NSIS installer set KISYSMOD to the install path
for all users.
Indeed, you are correct on NSIS. I think I've solved this issue optimally in
my own
software products, after 30 years.
I think last minute install redirects ala NSIS are important like this. One
way to do
this is through configuration files, since if we house them at known locations,
they in
turn can tell us anything. (In my software you can pass the known location on
the command
line to override a default, but this is overkill for this discussion.) The
configuration
file can tell us anything we want to listen to.
To have a meaningful conversation we have to encompass a lot more than
KISYSMOD, so let me
broaden just a litte and address some needs:
a) KISYSMOD is deliberately an environment variable, because the FP LIB TABLE
can handle
*any* number of environment variables, and we don't want to lose that feature.
However,
KISYSMOD is a special environment variable: Iff not set in the environment at
program
startup, just this one environment variable could be read from a configuration
file
setting, which is otherwise ignored if not set in the environment already.
CMake install
and NSIS both, can establish the initial setting in the the configuration file,
if that
setting is to be used in the event the setting is not in the environment at
program startup.
b) Any other environment variable can be used in the two FP LIB TABLEs without
us knowing
about it a priori.
c) The actual *initial* global fp lib table can be built ahead of time, with a
text
editor, one copy for *all* platforms, and in theory it will be the same for any
platform.
Just assume the user has a complete install of the existing repo within our
library
branch. And you are done.
As of today, it is attached: fp_global_table
And the script to generate it at any time is also attached: make_global_table.sh
If you like a), then simply read the variable out of the config file, and we
have to
augment our installers, both NSIS and CMake to set it.
The config file and global table would have to be accessible for all
users unless you were just installing it in your home folder. I guess
that means the config file goes in /etc on Linux and HKLM in the Windows
registry (at least for now until I can get around to dumping the kicad
registry settings to config files). I'm not sure where it would go on
OSX. The table itself can reside anywhere on the system that users have
read privileges.
The guesstimating was for existing installations. Since
the library search path is already valid and is one of the entries in
the library search list, on the surface it made sense to find the path
with the most libraries and use that path for KISYSMOD if it wasn't
already set. Certainly a hard coded path would make my job a lot easier.
On the unrelated subject of CMAKE_INSTALL_PREFIX, what we have now is the
possibility that
someone sets CMAKE_INSTALL_PREFIX into a wild blue yonder, and that the wild
blue yonder
dir is not in the list above, not even in "end_list", although it seems
everyone should
have an "end_list", just for good luck. Also, the poor guy who installs on
drive G: in
windows is hosed, of course that is another way of saying wild blue yonder.
I thought everybody installed their files in "end_list" :) This list is
not the complete list used to define the library search paths. The
executable path, several platform specific paths, and the KICAD
environment variable and several paths relative to these paths are added
the list of paths above at run time and then all of the paths that do no
exist are removed from the search list. While I agree this is less than
optimal, we will have to keep this in order to convert existing projects
over to the new footprint library table.
I can probably stuff an entry into the first of the table, so users can install
in wild
blue yonder. I really don't see how kicad can currently be installed on linux
without
being root, and that is one of my goals in this next bit of work.
But eventually these tables have to be re-thought. Maybe again, configuration
file
entries can deal with this also.
Dick
The installation system in CMake on Linux is actually at the top of my work
queue now.
Promise. I am one of those guys that does not benefit from linux packages, so
the
install() statements in CMakeLists.txt have greater ramifications for me than
most. It
would be nice to have the notion of a datapath and a codepath. I read about
that
somewhere. CMAKE_INSTALL_PREFIX can only serve one of those needs.
I have two excellent sets of patches to look over, and this should happen in
the next 10
days. I can give this option B some more thought at that time also, at least
the
cmakedefine. Your choice to use it is something for you to think about.
Dick
<<<snipped>>>
_______________________________________________
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
