Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack <re...@his.com>: > On 04/12/18 09:58, Carsten Schoenert wrote: > > Hi, > > Am 12.04.2018 um 15:47 schrieb Reece R. Pollack: > > I'm a relative newbie to KiCad, but I've been a software engineer since > the early 1980. I'd prefer to see KiCad installed in a self-contained > manner, meaning all installed files end up under one directory hierarchy > rather than being spread all over the filesystem. > > well, KiCad isn't installing "some there" and "all over" the various > systems. If you think so you have a impression that is different from > the reality. > > > The KiCad 4.0.7 Debian Linux package installs files in these directories: > > /etc/profile.d > /usr/bin > /usr/lib/kicad > /usr/lib/python2.7/dist-packages > /usr/share/applications > /usr/share/doc > /usr/share/icons > /usr/share/kicad > /usr/share/menu > /usr/share/mime > /usr/share/mimelnk > > That's "spread all over the file system" in contrast to my preference of > having all installed files under one directory. >
No, it is not, that i simply the unix/linux way or hatver the correct term is. You can just set the cmake install prefix or destdir when installing to /opt/kicad-foo and you get the same behaivour as with the xilinx tools. But this is not the topic of this thread, we should focus on the user config here. > But as I said, putting everything under one directory hierarchy (for > example, "/opt/kicad5") would be a significant change in behavior. A > reasonable alternative is to install using file and directory names which > include the major version number. Thus > > /usr/bin/kicad4 > /usr/bin/kicad5 > > and > > /usr/lib/kicad4/plugins/ > /usr/lib/kicad5/plugins/ > > I could even accept keeping the V4 file and directory names as they are > and merely appending a 5 to the new files and directories. > > This is how Xilinx > ISE, Eagle, and many other packages are installed, and it makes it very > easy to keep multiple versions. This would be a major change in > strategy, though. > > If all software projects would follow the common rules on the various > platform it would be easier for all. But especially Windows based > software follows often some "own" rules as it's simply possible. > > > I know many Windows programs install in self-contained directory > hierarchies now, as the previous behavior of overwriting DLLs in shared > directories caused major headaches. I do not develop for Windows, though, > so I'll leave that to those who are more familiar with that environment. > > > > Regardless, I agree that file names or paths should include the major > version number. The executable file "kicad" should be renamed "kicad5" > for V5. The directory under /usr/lib and /usr/share should be renamed > from "kicad" to "kicad5". And so on. Under Linux (or at least the > Debian-derived distros) the "update-alternatives" utility can be used to > select which version is run using the "kicad", "pcbnew", and "eeschema" > commands. > > updates-alternatives has a different approach as you think. It's not > designated for this solution you think off. > http://williamdemeo.github.io/linux/update-alternatives.html > > > I'm well aware of the purpose of update-alternatives; I'm quite familiar > with both its use and its implementation. > > Allow me to quote from the first paragraph of the link you provide: > > Here are some notes on update-alternatives and some examples > demonstrating its use. The purpose of the update-alternatives utility > program is to manage, on a single machine, serveral versions of programs > that all provide the same functionality. > > That is exactly what we're doing here: managing several versions of > programs that all provide the same functionality. Nothing in either the > implementation nor the intent of update-alternatives requires that the > different versions behave identically. > > A common case in the life of a developer is to have multiple versions of > the Gnu C/C++ compiler installed. Perhaps new development is done with the > GCC-5 compiler so it is the default on a system, but when producing an > update for older systems the GCC-4.8 version is used. The > update-alternatives allows the system manager to configure the system so > the "cc" command invokes the latest-and-greatest, but the older versions > are accessible by using the full file name. > > Here's the path the system follows to find the proper program to run for > the "cc" command on my system: > > /usr/bin/cc -> /etc/alternatives/cc > /etc/alternatives/cc -> /usr/bin/gcc > /usr/bin/gcc -> gcc-5 > /usr/bin/gcc-5 > > Using update-alternatives properly would require renaming the V4 files to > include the major version number, as well as naming the V5 file properly. > Perhaps there could be a 4.0.8 release that does this for coexistence. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
