kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack <reece@xxxxxxx>:

> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>