kicad-developers team mailing list archive

["Reece R. Pollack" <reece@xxxxxxx>]

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