kicad-developers team mailing list archive
Mailing list archive
Re: Re: New coding guidelines.
Dick Hollenbeck <dick@...>
Mon, 05 Jan 2009 18:31:42 -0600
Thunderbird 220.127.116.11 (X11/20081125)
Wayne Stambaugh wrote:
Dick Hollenbeck wrote:
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.
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_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
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 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.
Seems like a reasonable strategy. Everyone gets everything they
want. Just have to find time to code it all up, which is always the
hard part. Clarification and emphasis: FINDING TIME is the hard part,
not the coding.