I have just been observing this thread for a while and I’m wondering if (at least for *nix implementations) installing the files into a version specific sub-tree and putting links into the “unix/linux way” directories might be a solution - having a simple script change the links to enable a specific version would complement the setup. I may try this out in a virtual machine first because I’m stuck at 4.07 on my main Linux System right now while really bing interested in playing with a version 5 rc2.
Michael > On Apr 12, 2018, at 09:33, Reece R. Pollack <re...@his.com> wrote: > > On 04/12/18 11:38, Nick Østergaard wrote: >> Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack <re...@his.com >> <mailto: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. > > Agreed, it is. I've been working almost exclusively in the Linux environment > for the last 15 years of my career, including assembling distros from > scratch. But the name conflicts make maintaining several versions > concurrently rather difficult unless the application developers take care to > support it. > > Yes, I'm going a bit off the original topic. Maybe we should start a new > thread. But I see an issue arising in the future where people are going to > want to install V5 but not give up V4 quite yet. For example, board houses > that accept KiCad board files may not be ready to make a hard cut to V5 until > they're sure it's really ready, but they'd like to be able to accept V5 board > files. Right now that would be difficult without compiling from source and > installing in a separate directory. > > I'd hate to see KiCad miss this chance to embrace multiple installation > support just because we're thinking only of the testing environment. > > -Reece > _______________________________________________ > 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
