kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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