kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
>>> 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.
>> 
> 
> 
> I like the multiple paths. 
> 
> It is not clear to me what the environment variable brings that a well 
> placed, well designed configuration file does not bring. 
> 
> We may have to start getting more specific for this to be a fruitful 
> discussion. We will have to track down the code that is using these 
> hard coded paths. And see what facilities are using them, and if they 
> need to be hard coded.
> 
> I don't have a problem with a single global config file with a hard 
> coded name being put into a location that can be known ahead of time. 
> And from that config file other data files should be findable.

A single global config file is great for production. I always liked
environment variables for development. It's nice to be able to open a
shell and set the environment variable temporarily while your
developing. The problem with a config file is you have to remember to
set it back to after you change it for development purposes. I vote for
supporting an environment variable and a config file. If the
environment variable is set, add that path to the beginning of a path
list. Otherwise, just use the config file settings.

Wayne
> 
> Anyone else have thoughts on this?
> 
> Dick
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>