kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/19/2012 10:47 AM, Miguel Angel Ajo Pelayo wrote:
> Thanks Dick, I really like that idea. Seems quite clean, and flexible.
>
> In the case of Linux, when KiCad is installed system wide (apt-get for
> example), then, if this file could go in ~/.kicad/paths for example,


A choice is available there.  There are existing configuration files that could carry this
information, since it is simply a handful of name/value pairs, where name=category, and
value=directory.
Or you can use a new file reserved for that purpose.  An API for "directories" can hide
this choice, and allow changes behind the API later without affecting client code.


Remember that the "installation mechanism" must modify the name/value pairs comprising the
directory table to reflect the user's choice of directories for each category. 

    So lets examine one way to achieve this goal: modify the directory table during the
installation, regardless of where that table lives.  It could live in an existing config file.

As an interim or even medium term solution, one could do all this with CMake.  CMake's
"install" support is quite good.  Distro package maintainers can use the "install" support
inside their distro package build scripts without issue, I think.  Out of the box, CMake
supports CMAKE_INSTALL_PREFIX as a base installation directory for "install" commands. 
This comes into play when any paths passed to install() are not fully qualified.


    http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:install

However, since we are intending to transcend the single base directory model, and allow
users to scatter their KiCad files over a number of filesystems, (say network and local),
then this single variable is insufficient.  I would suggest junking CMAKE_INSTALL_PREFIX,
not using it.  You can do this by using CMake expressions to specify a FULL path when
invoking the CMake install() built-in.  You do not have to use CMAKE_INSTALL_PREFIX.  You
can have a separate cmake variable for each dir category, and then when "install(...)" is
run, it can put things where they are configured to go, and can also modify the directory
table, which might just be a handful of entries in a stock configuration file.

Well you might ask at this point, why not just compile in the choices made in the
CMakeCache.txt file?  Why have the directory table at all?  This is a good question.  I
can only think of two reasons why the directory table is superior:

a) the table documents where things are, without this you have no idea since the paths
would be compiled into the program binaries.

b) with the directory table you can move categories around without rebuilding the binaries.





> we might need to create it the first time user launches KiCad, right?

I don't think this is superior to using CMake to do it ahead of time, during the
installation process, as described above.


>
> --
>
> Right now, how does kicad know where are the default libraries installed?
>
>
>
>
> 2012/7/19 Dick Hollenbeck <dick@xxxxxxxxxxx>:
>> On 07/19/2012 05:38 AM, Edwin van den Oetelaar wrote:
>>> http://en.wikipedia.org/wiki/Program_Files
>>>
>>> Remember that 'Program Files' only is a default location for English installs...
>>> Would it make sense for a multi-user machine to have stuff installed in a personal
>>> directory instead of a system directory?
>>> I have seen systems that would check : ~/.application/ver123/plugins/script1.py and if
>>> stuff can not be found there go to other places so users can install specific things
>>> without impacting the other users.
>> At least one person will have to develop scripts.  That person would prefer "write access"
>> to the directory where the scripts live and evolve.
>>
>>
>> A more general observation:
>>
>> A good [commercial] software application would categorize its various files into a number
>> of categorical groups, and then give a mapping table to tell where that category of files
>> actually reside.
>>
>> This would allow some categories of files to be in a read only directory, and some in a
>> read/write directory, and each category of files to be relocatable based on the mapping table.
>>
>> Then you have to find the mapping table without scratching your head too much.
>>
>>
>> Simply saying that we should support installing in /home/<user> falls far short of the
>> general solution I mention above.  Our company has implemented the above strategy for our
>> commercial software applications, and it is pretty simple since there is already
>> infrastructure to read configuration files and lookup name/value pairs from the config files.
>>
>> Here the "name" is the file category, such as "footprint_libraries" or "python_scripts",
>> and the value is simply the path.  The installer has to be able to modify the
>> configuration file so that the paths get updated to the chosen directories during
>> installation.  With this scheme, you could have libraries on a company server, without
>> being forced to install the core executables from KiCad there also.
>>
>>
>> Get to work.
>>
>>
>> Dick
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>