kicad-developers team mailing list archive

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

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. 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.

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.

-Reece



On 04/12/18 06:39, Clemens Koller wrote:
> I would pretty much vote to use the IMO more common naming scheme for major package versions:
>
> kicad (the current one installed from the repository of your choice)
> kicad4 (currently: 4.0.7)
> kicad5 (currently: 5.0.0-rc2-dev...)
> kicad6 (tbd.)
>
> ...avoiding the ".v5" i've seen lately.
>
> I believe there is less demand for different minor versions installed next to each other, however it would be a nice-to-have.
> (So... a user-selectable configuration might help: $ kicad -c projectconfig.cfg)
>
> Regards,
>
> Clemens
>
> On 2018-04-12 09:33, Strontium wrote:
> > After considering my patch, what about the following proposal:
> >
> > Just change the hard coded string in common.cpp (at around line 243) from:
> >
> > cfgpath.AppendDir( wxT( "kicad" ) );
> >
> > to
> >
> > cfgpath.AppendDir( wxT( "kicad.v5" ) );
> >
> > (or some other string)
> >
> > Thats it.  Then Kicad Version 5 will have a unique configuration
> > directory that will not conflict with version 4.
> >
> > If an end user wants to bring their kicad V4 configuration over to v5,
> > they just copy it themselves.  Otherwise it starts with a brand new
> > blank configuration.  Alternatively packaging might be able to copy it
> > over.  But i don't see any real need to do it for the user at that
> > stage.  Its just a complication.
> >
> > Then when the development branch is forked, just rename this again to
> > something like:
> > cfgpath.AppendDir( wxT( "kicad.v6dev" ) );
> >
> > (or whatever).
> >
> > Then an end user can have V4, V5 and a Nightly all on the same machine
> > and configurations won't conflict.
> >
> > Anything more exotic can be deferred to V6 development.
> >
> > Steven
> >
> >
> >
> >
> > On 08/04/18 13:33, Carsten Schoenert wrote:
> > > Am 07.04.18 um 17:34 schrieb Strontium:
> > > > Attached is a patch for discussion only.
> > > >
> > > > Its the minimum change I could come up with to implement a unique
> > > > version specific config directory.
> > > >
> > > > Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
> > > > or Mac.
> > > > And on Linux, etc it will change from "~/.config/kicad" to
> > > > "~/somethingelse/kicad" which would work, but isn't a very friendly
> > > > naming scheme.
> > > Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
> > > pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
> > > $HOME/.local/share.
> > >
> > > I'm sure Windows and Mac have similar variables for the folders that
> > > should contain the logical same content.
> > >
> > > The path to the KiCad user config must based on such variables plus the
> > > preferred name for the config folder, so like kicad-5 (for KiCad5) and
> > > kicad-6 (for future version KiCad6) and kicad-nightly (for devel
> > > version). GTK is doing this for a long time.
> > >
> > > > $ find  ~/.config -type d -name gtk*
> > > > /home/carsten/.config/gtk-3.0
> > > > /home/carsten/.config/gtk-2.0
> > > If KiCad will introduce some version specific user config and data
> > > folders (which I appreciate to see) it will be needed to configured by
> > > the build environment and not hard-coded in the binaries. The variables
> > > can be overwritten with some additional value given while starting the
> > > applications.
> > >
> > > e.g.
> > > take the default folders
> > > $ kicad
> > >
> > > override the setting for the default config etc.
> > > $ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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