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 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>>>
