← Back to team overview

kicad-developers team mailing list archive

Re: kicad version and install location

 

There is a tool which allows developers to quickly switch between different versions of Ruby (and their associated gemsets).

Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas could be adapted for KiCad

https://rvm.io/


On 07/15/2018 09:52 AM, Adam Wolf wrote:
I guess the fact that environment variables are tricky to set for graphical applications for the Mac may be a blessing here :)

Should we try to package a macOS version that installs to /Applications/KiCad5 and /Library/Application Support/kicad?

Adam

On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx <mailto:eeli.kaikkonen@xxxxxxxxx>> wrote:

    There are some people in the user forum who have spent time with
    these v4->v5 problems, including me and Rene. The consensus about
    the environment variables seems to be what Rene already said, that
    they should not (without explicit user intervention) be set for
    the system, but from KiCad itself. Nick confirmed that the current
    v5 installer won't set them by default. They are still a problem
    if they have been set by v4 installer.

    su 15. heinäk. 2018 klo 5.04 Strontium (strntydog@xxxxxxxxx
    <mailto:strntydog@xxxxxxxxx>) kirjoitti:

        I honestly think each major revision of KiCad should be
        considered a NEW
        program, installs to a new place has its configuration and
        libraries all
        in a new location.  Only Incremental updates 5.0 -> 5.1 should be
        considered upgrades.


    I agree. It's probable that many users will want to continue with
    v4 for old projects but v5 for new, and in the future the same
    thing will be true for v5 vs. v6, because they break the
    file/project compatibility. But where the compatibility is kept
    it's more likely to be considered as just an upgrade.

        Kicad configuration isn't complex or onerous so if a user
        wants to bring
        a Kicad4 config into Kicad5 or 6 or whatever, then they do that
        themselves, otherwise after install Kicad5 is a fresh blank
        sheet with
        no relationship to anything that happened on the users
        computer in
        Kicad4.  I am not familiar with the issues on Windows, but I
        would have
        thought now this is mostly a packaging issue only??


    I tried modifying the Windows installer, I only needed to replace
    some of "KiCad" strings with "KiCad5" and it can install v5
    alongside v4 independently. The only problem is the configuration
    and the environment variables set by v4. They can be handled with
    a startup script. See
    https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282
    for some details.

        I also agree if it can't work this way now on Windows, then
        its all a
        bit late for V5, but maybe V6 can consider itself a new
        program distinct
        from V5.  This would also help with testing, because users
        could use V5
        for daily work, but also easily install a V6 daily side by side.


    All this could be done with the Windows installer, provided that a
    startup script would be offered.

    To make this all, at least the startup script, as simple as
    possible I would suggest one (or three) small changes to KiCad
    (for 5.1, or even 5.0.1?). Add command line options
    --config=/path/to/config and --ignore-env-vars. The former is
    obvious and would override KICAD_CONFIG_HOME system environment
    variable. The latter would make KiCad ignore all system
    environment variables and use the current internal logic and the
    path settings UI instead. That way the old variables could be left
    for v4 and the newer versions would be completely independent if
    the command line switches were used. The command line switch for
    the config path would be mostly for convenience. In Windows
    starting a program with custom environment variables is tedious
    and error prone to write (see the above mentioned thread). Command
    line switches are much easier.

    It could also be possible to make --ignore-env-vars=true by
    default. Sharing the environment variables would be a special case
    if the user wants that.

    The general problem with using system environment variables is
    that they are good for situations when there's only one version of
    a program on the system, and/or several processes share the same
    variable values. Neither of them is true for parallel
    installations of KiCad.

    Eeli Kaikkonen
    _______________________________________________
    Mailing list: https://launchpad.net/~kicad-developers
    <https://launchpad.net/%7Ekicad-developers>
    Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~kicad-developers
    <https://launchpad.net/%7Ekicad-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


Follow ups

References