kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> Dick Hollenbeck wrote:
>> 
>>> wafeliron wrote:
>>> 
>>>> For example its hard to
>>>> find the hardcoded paths in the source and this is a real LACK if i
>>>> install on linux and dont want to but it in the root directory. I
>>>> would like to work on it but its not well commented and structured
>>>> into files about reading the .KiCad .pcbnew files ...
>>>> 
>>>> 
>>> I agree that the linux install could be improved. I would like the 
>>> installed data tree to be separate from the code tree, optionally.
>>>
>>>
>>> I would like to be able to put the code in /opt/kicad or 
>>> /home/dick/kicad and cannot do that now. And I would like to put the 
>>> data tree in /home/dick/kicaddata for example.
>>>
>>>
>>> CMake would need to spit out some C++ code containing the selected paths 
>>> and then that would be used instead of the hard coded paths in gestfiche.cpp
>>>
>>>
>>> There may be ways, but this seems workable to me.
>>> 
>> Using relative paths may be an usable if not a particularly elegant
>> solution. The CMake default installs files using the typical (if there
>> is actually such a thing as typical) Linux file system hierarchy where
>> executables are installed in /bin and data and doc files are installed
>> in share/kicad/ relative to CMAKE_INSTALL_PREFIX. Even running "make
>> install" in Windows will preserve this heirarchy albeit typically under
>> "c:\Program Files\Kicad". If you don't deviate from this pattern you
>> can always find the data and doc files relative the executable path.
>> This has the advantage of being able to install development versions in
>> a non-standard path for debugging purposes.
>>
>> Wayne
>>
>> 
> 
> Wayne,
> 
> Yes I think you have the same understanding of the status quo as I do. 
> But unless I misunderstand you, I do not think your solution addresses 
> the weakness that I pointed out.
> 
> In a simple scenario, say you wanted to have the binaries in one place, 
> say on a network drive, and you wanted to install the data files, such 
> as libraries, etc elsewhere, the fact that these are tied to the same 
> root tree is a restriction that is too harsh in my opinion. It is 
> common in linux/unix to have two separate trees one for app binaries and 
> one for app data.
> 
> I simply following a time honored trend. To do it, there needs to be a 
> separate anchor path for the data part of the tree, not tied to 
> CMAKE_INSTALL_PREFIX.
> 
> CMAKE_INSTALL_BINARIES_PREFIX and CMAKE_INSTALL_DATA_PREFIX or similar.
> 
> 
> Why is this time honored?
> 
> Only an administrator might have authority to update the program files, 
> whereas each user might be given authority to control his own data. 
> This kind of thinking comes not from me. I believe some of it is 
> discussed in the LSB document.
> 
> It is simply a matter of adding and decoupling CMAKE variables. They 
> can default to the same however. Then we need to change where the data 
> files are found. This is either autogenerating a hard coded path at 
> installation time, or by testing an environment variable.
> 
> Another scenario is when somebody, say a developer, wants multiple 
> binaries, but only a single copy of the libraries and application data.
I misunderstood the problem. I was looking at the problem from
installing both the binaries and the data in non-standard location for
development purposes as opposed to using the standard data with
development binaries. As of now, if the standard library paths are not
found, you get a bunch of library not found messages.
> 
> This is not a lot of work, and I think it would add value to a user's 
> experience.
I think the environment variable is workable as long as it supports
multiple paths. This would give the user the option to define the
library path search order as well.
> 
> Dick
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>