kicad-developers team mailing list archive

[Jean-Samuel Reynaud <js.reynaud@xxxxxxxxx>]

Perhaps this name should be configurable ("overridable" ?) by an env
variable ?


Le 12/04/2018 à 15:29, Strontium a écrit :
> kicad5
> kicad6
> etc etc works for me.  I am not wedded to my suggestion, it was
> illustrative only.
> 
> For backward compatibility, "kicad" would be for kicad4 because that's
> what it uses now, so there would be no "kicad4".
> 
> I agree that a user selectable configuration directory would be useful
> for some people.  It should not be difficult to do either, once there
> was a consensus on the how of it. However, being cognizant of how late
> in the release stage for V5 it is, this proposal to only change the base
> directory is to allow kicad4 and 5 to coexist (and nightlies) in the
> absolutely simplest possible way, without creeping the scope, or
> creating untested code paths or boundary cases.  I also don't feel that
> it creates a burden going forward, or precludes the development team
> expanding on this or any other changes to this area that are felt
> desirable.  I think we should push anything more exotic than just using
> a new base configuration directory to version 6.
> 
> Steven
> 
> On 12/04/18 18: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
> 
> 
> 
> _______________________________________________
> 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