kicad-developers team mailing list archive

[Michael Frank <michael@xxxxxxx>]

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 <reece@xxxxxxx> wrote:
> 
> On 04/12/18 11:38, Nick Østergaard wrote:
>> Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack <reece@xxxxxxx <mailto: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.
> 
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp