This is a large topic, so I'm creating a new thread.
http://www.gnu.org/prep/standards/html_node/Directory-Variables.html They have datadir and datarootdir which are for readonly data, essentially the same thing, both for *readonly* data. CMake recently introduced a patch to support a lot of this: http://www.cmake.org/pipermail/cmake-commits/2011-March/010379.html It seems the CMake var CMAKE_INSTALL_DATADIR is within reach for us now, and it is *intended* for readonly data. For me, readonly data is not worth a lot of special treatment, it CAN be based off the same prefix. I guess my larger concern is with writable data files, and where they should go. It would be nice if the project manager created the first project in this directory, whatever you want to call it. Is this enough of a reason to ask for a writable data dir during a CMake based installation? This would be possibly for personal libraries also. Dick > > 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. > > 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. > > > 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 > > > _______________________________________________ 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
