kicad-developers team mailing list archive
Mailing list archive
Re: Re: New coding guidelines.
Dick Hollenbeck <dick@...>
Sun, 04 Jan 2009 17:02:36 -0600
Thunderbird 220.127.116.11 (X11/20081125)
Wayne Stambaugh wrote:
Dick Hollenbeck wrote:
I agree that the linux install could be improved. I would like the
installed data tree to be separate from the code tree, optionally.
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 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.
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.
This is not a lot of work, and I think it would add value to a user's