Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Simon Richter]

Hi,

On 04/12/2018 06:41 PM, Michael Frank wrote:

> 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

You are describing GNU Stow.

   Simon

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Michael Frank]

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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Carsten Schoenert]

Am 12.04.18 um 18:33 schrieb Reece R. Pollack:

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

This is mainly no problem of the upstream KiCad project, it's more a
problem then on the distributions side.
Even right now it's possible to build both versions and install them
independently on your system.

-- 
Regards
Carsten

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Reece R. Pollack]

On 04/12/18 11:38, Nick Østergaard wrote:
Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack >:


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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Carsten Schoenert]

Am 12.04.18 um 17:18 schrieb Reece R. Pollack:
> 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

I know this, as I do this for Debian. ;)

> That's "spread all over the file system" in contrast to my preference of 
> having all installed files under one directory.

Your personal preferences are colliding with the LFS and FHS, all the
directories above are defined by them and the KiCad packages are comply
with. All those folders are quite not interesting for normal users
without system privileges and users definitely shouldn't change here
anything. We need to talk about how the possibilities are user can
override files from the packages without conflicting with them. So I
don't see your point here.

> But as I said, putting everything under one directory hierarchy (for 
> example, "/opt/kicad5") would be a significant change in behavior.

You can use this folder in your own, but for all Debian based distros
this is a no go.

> A 
> reasonable alternative is to install using file and directory names 
> which include the major version number. Thus
> 
> /usr/bin/kicad4
> /usr/bin/kicad5
> 
> and
> 
> /usr/lib/kicad4/plugins/
> /usr/lib/kicad5/plugins/
> 
> I could even accept keeping the V4 file and directory names as they are 
> and merely appending a 5 to the new files and directories.

Currently I don't see a real need to make the old version 4.0.7
co-installable. This version is about 1.25 years ago from today with the
last point update about 7 months ago.

Making KiCad 5 and KiCad nightly installable (on Linux) in parallel
isn't that difficult. You need to adjust only the desktop files for the
various application.

But the internal logic of KiCad for searching libraries and
configuration is something that's need to be done by the developers.

> I know many Windows programs install in self-contained directory 
> hierarchies now, as the previous behavior of overwriting DLLs in shared 
> directories caused major headaches. I do not develop for Windows, 
> though, so I'll leave that to those who are more familiar with that 
> environment.

Windows uses a different mechanism of symbol lookups so it's a home made
problem on Windows based platform if you have to deal with that
platform. Most applications are simply ship their own dll files to get
the horse ridden.

So far I remember a good explanation about the voodoo on windows system
can be found in the book 'Autotools: A Practioner's Guide to GNU
Autoconf, Automake, and Libtool' from John Calcote.

> https://www.amazon.com/gp/product/1593272065

...
> I'm well aware of the purpose of update-alternatives; I'm quite familiar 
> with both its use and its implementation.
> 
> Allow me to quote from the first paragraph of the link you provide:
> 
> Here are some notes on |update-alternatives| and some examples
> demonstrating its use. The purpose of the update-alternatives
> utility program is to manage, on a single machine, serveral versions
> of programs that all provide the same functionality.
> 
> That is exactly what we're doing here: managing several versions of 
> programs that all provide the same functionality.

No, we don't. And we don't need this. The whole thread is about
installing various versions of KiCad in parallel and also be able to
start them independently.

update-alternatives is simply to provide a common name that is pointing
to a real binary. The only use case could be to provide a name 'kicad'
that would pointing to 'kicad5' e.g.

Do we really need this? I don't think so.

> Nothing in either the 
> implementation nor the intent of update-alternatives requires that the 
> different versions behave identically.
> 
> A common case in the life of a developer is to have multiple versions of 
> the Gnu C/C++ compiler installed. Perhaps new development is done with 
> the GCC-5 compiler so it is the default on a system, but when producing 
> an update for older systems the GCC-4.8 version is used. The 
> update-alternatives allows the system manager to configure the system so 
> the "cc" command invokes the latest-and-greatest, but the older versions 
> are accessible by using the full file name.
> 
> Here's the path the system follows to find the proper program to run for 
> the "cc" command on my system:
> 
> /usr/bin/cc -> /etc/alternatives/cc
> /etc/alternatives/cc -> /usr/bin/gcc
> /usr/bin/gcc -> gcc-5
> /usr/bin/gcc-5
> 
> Using update-alternatives properly would require renaming the V4 files 
> to include the major version number, as well as naming the V5 file 
> properly. Perhaps there could be a 4.0.8 release that does this for 
> coexistence.

No, not needed.

ln -s /usr/bin/kicad /usr/lib/kicad/kicad

vs.

ln -s /usr/bin/kicad /usr/lib/kicad5/kicad5 ???

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Kaspar Emanuel]

Is it usefull ?

Yes! Thank you ver much. I like to report bugs against nightly but don’t
always have time to compile and I need a fairly stable KiCad for other
work. I switched away from your daily ppa (ppa-kicad) since the schematic
lib table changes hit because I didn’t have time to deal with that.

I just managed to install kicad-nightly from
ppa:js-reynaud/ppa-kicad-nightly and used it to test if a feature request I
wanted to make hadn’t already been implemented.
​

On 4 April 2018 at 10:52, Jean-Samuel Reynaud  wrote:

> Dear All,
>
>
> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
> requests about installing daily build packages in parallel with stable
> version.
> With next version (V5) I think it can be useful...
> FreeCad provide this kind of feature and you are able to run both
> version in parallel.
>
> For testing that I had created a dedicated PPA:
> ppa:js-reynaud/kicad-dev-daily
> (to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev-daily)
>
> Once added, you are able to install a new package "kicad-daily" that
> won't conflict with existing "kicad" packages.
> All files are installed on a separate folder and commands became
> "something-daily". For example kicad-daily or pcbnew-daily...
>
> So my questions are:
> - Is it usefull ?
> - Is it a bad idea/stupid :( ?
> - If you test it, are you able to find some limitations/bugs ?
> - Perhaps to have is plainly functional some modifications are needed.
> What modifications ?
>
>
> For the moment, you can't run in same time two versions (or there are
> some error messages...) anyway both are installed and easily "runnable"...
>
>
> Please give your comments, feedbacks...
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Nick Østergaard]

Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack :

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


> But as I said, putting everything under one directory hierarchy (for
> example, "/opt/kicad5") would be a significant change in behavior. A
> reasonable alternative is to install using file and directory names which
> include the major version number. Thus
>
> /usr/bin/kicad4
> /usr/bin/kicad5
>
> and
>
> /usr/lib/kicad4/plugins/
> /usr/lib/kicad5/plugins/
>
> I could even accept keeping the V4 file and directory names as they are
> and merely appending a 5 to the new files and directories.
>
> 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.
>
> If all software projects would follow the common rules on the various
> platform it would be easier for all. But especially Windows based
> software follows often some "own" rules as it's simply possible.
>
>
> I know many Windows programs install in self-contained directory
> hierarchies now, as the previous behavior of overwriting DLLs in shared
> directories caused major headaches. I do not develop for Windows, though,
> so I'll leave that to those who are more familiar with that environment.
>
>
>
> 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.
>
> updates-alternatives has a different approach as you think. It's not
> designated for this solution you think off.
> http://williamdemeo.github.io/linux/update-alternatives.html
>
>
> I'm well aware of the purpose of update-alternatives; I'm quite familiar
> with both its use and its implementation.
>
> Allow me to quote from the first paragraph of the link you provide:
>
> Here are some notes on update-alternatives and some examples
> demonstrating its use. The purpose of the update-alternatives utility
> program is to manage, on a single machine, serveral versions of programs
> that all provide the same functionality.
>
> That is exactly what we're doing here: managing several versions of
> programs that all provide the same functionality. Nothing in either the
> implementation nor the intent of update-alternatives requires that the
> different versions behave identically.
>
> A common case in the life of a developer is to have multiple versions of
> the Gnu C/C++ compiler installed. Perhaps new development is done with the
> GCC-5 compiler so it is the default on a system, but when producing an
> update for older systems the GCC-4.8 version is used. The
> update-alternatives allows the system manager to configure the system so
> the "cc" command invokes the latest-and-greatest, but the older versions
> are accessible by using the full file name.
>
> Here's the path the system follows to find the proper program to run for
> the "cc" command on my system:
>
> /usr/bin/cc -> /etc/alternatives/cc
> /etc/alternatives/cc -> /usr/bin/gcc
> /usr/bin/gcc -> gcc-5
> /usr/bin/gcc-5
>
> Using update-alternatives properly would require renaming the V4 files to
> include the major version number, as well as naming the V5 file properly.
> Perhaps there could be a 4.0.8 release that does this for coexistence.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : 

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Reece R. Pollack]

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.


But as I said, putting everything under one directory hierarchy (for 
example, "/opt/kicad5") would be a significant change in behavior. A 
reasonable alternative is to install using file and directory names 
which include the major version number. Thus


/usr/bin/kicad4
/usr/bin/kicad5

and

/usr/lib/kicad4/plugins/
/usr/lib/kicad5/plugins/

I could even accept keeping the V4 file and directory names as they are 
and merely appending a 5 to the new files and directories.



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.

If all software projects would follow the common rules on the various
platform it would be easier for all. But especially Windows based
software follows often some "own" rules as it's simply possible.


I know many Windows programs install in self-contained directory 
hierarchies now, as the previous behavior of overwriting DLLs in shared 
directories caused major headaches. I do not develop for Windows, 
though, so I'll leave that to those who are more familiar with that 
environment.






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.

updates-alternatives has a different approach as you think. It's not
designated for this solution you think off.

http://williamdemeo.github.io/linux/update-alternatives.html


I'm well aware of the purpose of update-alternatives; I'm quite familiar 
with both its use and its implementation.


Allow me to quote from the first paragraph of the link you provide:

   Here are some notes on |update-alternatives| and some examples
   demonstrating its use. The purpose of the update-alternatives
   utility program is to manage, on a single machine, serveral versions
   of programs that all provide the same functionality.

That is exactly what we're doing here: managing several versions of 
programs that all provide the same functionality. Nothing in either the 
implementation nor the intent of update-alternatives requires that the 
different versions behave identically.


A common case in the life of a developer is to have multiple versions of 
the Gnu C/C++ compiler installed. Perhaps new development is done with 
the GCC-5 compiler so it is the default on a system, but when producing 
an update for older systems the GCC-4.8 version is used. The 
update-alternatives allows the system manager to configure the system so 
the "cc" command invokes the latest-and-greatest, but the older versions 
are accessible by using the full file name.


Here's the path the system follows to find the proper program to run for 
the "cc" command on my system:


   /usr/bin/cc -> /etc/alternatives/cc
   /etc/alternatives/cc -> /usr/bin/gcc
   /usr/bin/gcc -> gcc-5
   /usr/bin/gcc-5

Using update-alternatives properly would require renaming the V4 files 
to include the major version number, as well as naming the V5 file 
properly. Perhaps there could be a 4.0.8 release that does this for 
coexistence.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

On 12/04/18 21:49, Jean-Samuel Reynaud wrote:

Perhaps this name should be configurable ("overridable" ?) by an env
variable ?
Yes I think so too.  We have two proposals so far, an environment 
variable, or a command line switch.  Either or both would work.  But 
both are creeping the scope and if we do that, we should do it in V6.  
The decision here is, do we want to have kicad5 keep its configuration 
separate from kicad4 now.  OR do we want to wait until v6 and implement 
these other ideas when we have time to test them and shake out the 
issues. Which will mean kicad4 and 5 can not coexist.


My vote is we just change the already hard coded "kicad" subdirectory 
name to be "kicad5" (or whatever), and that we do that now before kicad5 
is released. Hardcoding "kicad" is no more or less evil than hardcoding 
"kicad5".  Any changes beyond that are deferred to V6 when they can be 
properly considered, implemented and tested.


NOTE: on any platform other than Windows and Mac, the root configuration 
directory can already be changed with an environment variable.  So you 
can change ~/.config/kicad to ~/my_extra_config/kicad but you can not 
change the name of the kicad subdirectory itself.


Steven



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 

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Carsten Schoenert]

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.

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

If all software projects would follow the common rules on the various
platform it would be easier for all. But especially Windows based
software follows often some "own" rules as it's simply possible.

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

updates-alternatives has a different approach as you think. It's not
designated for this solution you think off.

http://williamdemeo.github.io/linux/update-alternatives.html

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Jean-Samuel Reynaud]

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@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: 

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[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. 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Clemens Koller]

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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

Hell Carsten,

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.
yes, its not obvious from the patch I sent, because I left that code 
unmodified, but the config path is obtained using the wx call: 
wxStandardPaths::Get().GetUserConfigDir()  Kicad doesn't know about the 
platform specifics, it relies on wx to provide them.


ONLY if the platform is not windows or mac will it also read 
"XDG_CONFIG_HOME" and use that for the base of the configuration 
directories.  My patch does not change how kicad gets the configuration 
path, it only allows there to be two paths and if it has to create the 
current path, it copies the configuration from the previous config path, 
in order that current configuration is preserved on a version upgrade 
but not changed for the previous version.


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.
I suspected as much, however I do not know how one would go about that 
for kicad.  As to whether we do this now, later, or at all, The jury is 
still out, I just was looking at the scope of the change should kicad 
decide to do something like this.

  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

It would be easy enough to add a unique environment variable which 
superseded XDG_CONFIG_HOME if set.  Is this portable to windows and mac 
though?



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Carsten Schoenert]

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

-- 
Regards
Carsten

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

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


So, what I did is:
Define a previous config dir and a current one.  They can not be sub 
directories of one another, so I went with "kicad.v5" for the new config 
directory.  For a nightly we could use "kicad.v6dev" or some such.


HOW these constants should get assigned I don't know.  At the moment I 
hard coded them.


I changed GetKicadConfigPath() to take a parameter of the config 
subdirectory, and renamed the function to just GetConfigPath().
Added a new GetKicadConfigPath() which works like the old one, but uses 
the new parametrised GetConfigPath().
IF the current config path does not exist, we make it (Same 
functionality as before), except then we check if the old one exists, 
and if it does, we just copy everything from it into the new one, once.  
If the new config path already exists we ignore the old one all together.


Very first time this runs will be slower than normal (due to the file 
copy), every other time it should be exactly the same as it is now.


As far as I know wx does not have a copy directories function, but there 
is one in their forums, so I pulled that, and made some small changes to 
remove redundancy in the code.  Its a pretty straight forward recursive 
copy.  I don't know if this should stay in this file, or live elsewhere, 
or be re-written/re-named.


Patch attached.  Tested on Linux, and seems to work fine.  Should work 
on Windows and MAC, but I haven't tested on those.  ALL programs use the 
GetKicadConfigPath() function to get the base of the configuration (as 
far as I can tell), there should be no strange corner cases.



diff --git a/common/common.cpp b/common/common.cpp
index c547b60f3..77002f473 100644
--- a/common/common.cpp
+++ b/common/common.cpp
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -215,7 +216,57 @@ wxConfigBase* GetNewConfig( const wxString& aProgName )
 }
 
 
-wxString GetKicadConfigPath()
+// Taken from:
+//https://forums.wxwidgets.org/viewtopic.php?t=2080
+//Slightly modified for kicad use.
+bool wxCopyDir(wxString sFrom, wxString sTo, bool noFromOK = false)
+{
+// Fix paths
+if (sFrom[sFrom.Len() - 1] != '\\' && sFrom[sFrom.Len() - 1] != '/') sFrom += wxFILE_SEP_PATH;
+if (sTo[sTo.Len() - 1] != '\\' && sTo[sTo.Len() - 1] != '/') sTo += wxFILE_SEP_PATH;
+
+// Make destination directory
+if (!wxDirExists(sTo)) {
+if (!wxFileName::Mkdir(sTo, wxS_DIR_DEFAULT, wxPATH_MKDIR_FULL)) {
+wxLogError(wxT("%s could not be created!"), sTo.c_str());
+return false;
+}
+}
+
+// Check if source directory exists
+if (!::wxDirExists(sFrom)) {
+if (noFromOK) return true;
+wxLogError(wxT("%s does not exist!\r\nCan not copy directory"), sFrom.c_str());
+return false;
+}
+
+// Copy from Source to Destination
+wxDir fDir(sFrom);
+wxString sNext = wxEmptyString;
+bool bIsFile = fDir.GetFirst();
+while (bIsFile) {
+const wxString sFileFrom = sFrom + sNext;
+const wxString sFileTo = sTo + sNext;
+if (::wxDirExists(sFileFrom)) {
+wxCopyDir(sFileFrom, sFileTo);
+}
+else {
+if (!::wxFileExists(sFileTo)) {
+if (!::wxCopyFile(sFileFrom, sFileTo)) {
+wxLogError(wxT("Could not copy %s to %s !"), sFileFrom.c_str(), sFileTo.c_str());
+return false;
+}
+}
+}
+bIsFile = fDir.GetNext();
+}
+return true;
+}
+
+#define KICAD_PREVIOUS_CONFIG wxT( "kicad" )
+#define KICAD_CURRENT_CONFIG  wxT( "kicad.v5" )
+
+wxFileName GetConfigPath( wxString name )
 {
 wxFileName cfgpath;
 
@@ -240,11 +291,24 @@ wxString GetKicadConfigPath()
 }
 #endif
 
-cfgpath.AppendDir( wxT( "kicad" ) );
+cfgpath.AppendDir( name );
+
+return cfgpath;
+}
+
+
+wxString GetKicadConfigPath()
+{
+wxFileName cfgpath;
+
+cfgpath = GetConfigPath( KICAD_CURRENT_CONFIG );
 
 if( !cfgpath.DirExists() )
 {
-cfgpath.Mkdir( wxS_DIR_DEFAULT, wxPATH_MKDIR_FULL );
+// No Current Config, so get the path of the previous config.
+// and copy everything from it.
+wxCopyDir( GetConfigPath( KICAD_PREVIOUS_CONFIG ).GetPath(), 
+   cfgpath.GetPath(), true );
 }
 
 return cfgpath.GetPath();
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Clemens Koller]

Does it make sense to include the major version in the package name as well, 
just to give it a grab handle?

kicad4-4.0.7
kicad5-5.0.0
kicad5-nightly

See qt, gtk, ...

Regards,

Clemens

On 2018-04-06 08:01, Strontium wrote:
> Hi Wayne,
> 
> I agree with you about scope creep, however I do see issues for users.
> 
>  From an end user perspective V5 is a big change. I noticed big changes 
> just from missing nightly updates for 2 months.  There may be an 
> extended period of time when a user will want to run both versions, for 
> many reasons.
> 
> 
> On 06/04/18 01:54, Wayne Stambaugh wrote:
>> We should defer this to v6 unless the fix is simple with little or no
>> risk of introducing new bugs.  I know it would be nice to have but I
>> could say that about a lot of things.  Scope creep will prevent us from
>> ever delivering v5.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/5/2018 12:25 PM, Seth Hillbrand wrote:
>>> If we are going to support multiple versions, on the developer side, we
>>> should add a preference versioning to the user configuration directory.
>>> Otherwise, fp-lib-table will being either pointing to v4 or v5
>>> footprints.  Likewise, there are a few preferences that only exist in v5
>>> and will be lost when v4 saves the preference file.
>>>
>>> To avoid cluttering the config directory, we could place the v5
>>> configurations in a v5 sub directory.  Configurations would be
>>> preferentially loaded from the v5 directory with a fall-back to the v4
>>> items if v5 items were not found.  Configurations would only be saved to
>>> the v5 subdir.
> I agree with this, except I think we should ONLY read the V4 config 
> once, when the program detects there is no V5 config sub directory at 
> all.  After the V5 config is made and saved, the V4 config should be 
> ignored, and they should diverge from that point.
> 
> I don't know this code at all, but If no one else is doing it, I can try 
> and look at it over the weekend.  But I wont waste time if the decision 
> is already final.
> 
> If we don't do this can I propose that the V5 packaging make a backup of 
> the V4 config so that end users at least have the option of reverting 
> without their config being lost.
> 
> Steven
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Fabrizio Tappero]

Hi,
As for freecad I think it is a great idea to have v5 and kicad-nightly.

Cheers
Fabrizio


On Apr 6, 2018 8:02 AM, "Strontium"  wrote:

> Hi Wayne,
>
> I agree with you about scope creep, however I do see issues for users.
>
> From an end user perspective V5 is a big change. I noticed big changes
> just from missing nightly updates for 2 months.  There may be an extended
> period of time when a user will want to run both versions, for many reasons.
>
>
> On 06/04/18 01:54, Wayne Stambaugh wrote:
>
>> We should defer this to v6 unless the fix is simple with little or no
>> risk of introducing new bugs.  I know it would be nice to have but I
>> could say that about a lot of things.  Scope creep will prevent us from
>> ever delivering v5.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/5/2018 12:25 PM, Seth Hillbrand wrote:
>>
>>> If we are going to support multiple versions, on the developer side, we
>>> should add a preference versioning to the user configuration directory.
>>> Otherwise, fp-lib-table will being either pointing to v4 or v5
>>> footprints.  Likewise, there are a few preferences that only exist in v5
>>> and will be lost when v4 saves the preference file.
>>>
>>> To avoid cluttering the config directory, we could place the v5
>>> configurations in a v5 sub directory.  Configurations would be
>>> preferentially loaded from the v5 directory with a fall-back to the v4
>>> items if v5 items were not found.  Configurations would only be saved to
>>> the v5 subdir.
>>>
>> I agree with this, except I think we should ONLY read the V4 config once,
> when the program detects there is no V5 config sub directory at all.  After
> the V5 config is made and saved, the V4 config should be ignored, and they
> should diverge from that point.
>
> I don't know this code at all, but If no one else is doing it, I can try
> and look at it over the weekend.  But I wont waste time if the decision is
> already final.
>
> If we don't do this can I propose that the V5 packaging make a backup of
> the V4 config so that end users at least have the option of reverting
> without their config being lost.
>
> Steven
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

Hi Wayne,

I agree with you about scope creep, however I do see issues for users.

From an end user perspective V5 is a big change. I noticed big changes 
just from missing nightly updates for 2 months.  There may be an 
extended period of time when a user will want to run both versions, for 
many reasons.



On 06/04/18 01:54, Wayne Stambaugh wrote:

We should defer this to v6 unless the fix is simple with little or no
risk of introducing new bugs.  I know it would be nice to have but I
could say that about a lot of things.  Scope creep will prevent us from
ever delivering v5.

Cheers,

Wayne

On 4/5/2018 12:25 PM, Seth Hillbrand wrote:

If we are going to support multiple versions, on the developer side, we
should add a preference versioning to the user configuration directory.
Otherwise, fp-lib-table will being either pointing to v4 or v5
footprints.  Likewise, there are a few preferences that only exist in v5
and will be lost when v4 saves the preference file.

To avoid cluttering the config directory, we could place the v5
configurations in a v5 sub directory.  Configurations would be
preferentially loaded from the v5 directory with a fall-back to the v4
items if v5 items were not found.  Configurations would only be saved to
the v5 subdir.
I agree with this, except I think we should ONLY read the V4 config 
once, when the program detects there is no V5 config sub directory at 
all.  After the V5 config is made and saved, the V4 config should be 
ignored, and they should diverge from that point.


I don't know this code at all, but If no one else is doing it, I can try 
and look at it over the weekend.  But I wont waste time if the decision 
is already final.


If we don't do this can I propose that the V5 packaging make a backup of 
the V4 config so that end users at least have the option of reverting 
without their config being lost.


Steven

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Wayne Stambaugh]

We should defer this to v6 unless the fix is simple with little or no
risk of introducing new bugs.  I know it would be nice to have but I
could say that about a lot of things.  Scope creep will prevent us from
ever delivering v5.

Cheers,

Wayne

On 4/5/2018 12:25 PM, Seth Hillbrand wrote:
> If we are going to support multiple versions, on the developer side, we
> should add a preference versioning to the user configuration directory. 
> Otherwise, fp-lib-table will being either pointing to v4 or v5
> footprints.  Likewise, there are a few preferences that only exist in v5
> and will be lost when v4 saves the preference file.
> 
> To avoid cluttering the config directory, we could place the v5
> configurations in a v5 sub directory.  Configurations would be
> preferentially loaded from the v5 directory with a fall-back to the v4
> items if v5 items were not found.  Configurations would only be saved to
> the v5 subdir.
> 
> If we want to support this, we should insert this code before rc2. 
> Thoughts?
> 
> -S
> 
> 2018-04-04 22:24 GMT-07:00 Strontium  >:
> 
> On 04/04/18 18:52, Jean-Samuel Reynaud wrote:
> 
> So my questions are:
> - Is it usefull ?
> 
> 
> Having both versions be able to be installed side by side is
> immensely valuable for an end user, and the development of kicad, in
> my opinion.
> 
> The users can "USE" the stable version for their work.  They can
> also test the Nightly and not worry about it messing with their
> work.  It should mean that general users have a better chance to
> test the new version as it evolves, and they will feel more
> involved, even if that involvement is only posting bugs.  They don't
> have to choose between being on the bleeding edge, and being productive.
> 
> It would be equally useful (maybe even more useful) to have kicad V4
> and V5 installed simultaneously as well.
> 
> Steven
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Ouabache Designworks]

On Thu, Apr 5, 2018 at 9:25 AM, Seth Hillbrand 
wrote:

> If we are going to support multiple versions, on the developer side, we
> should add a preference versioning to the user configuration directory.
> Otherwise, fp-lib-table will being either pointing to v4 or v5 footprints.
> Likewise, there are a few preferences that only exist in v5 and will be
> lost when v4 saves the preference file.
>
> To avoid cluttering the config directory, we could place the v5
> configurations in a v5 sub directory.  Configurations would be
> preferentially loaded from the v5 directory with a fall-back to the v4
> items if v5 items were not found.  Configurations would only be saved to
> the v5 subdir.
>
> If we want to support this, we should insert this code before rc2.
> Thoughts?
>
> -S
>
>
Don't use a global config directory at all. Use a local config directory
relative to the directory where you are running kicad. If that is your home
directory then you will use the same one as you currently use. If you run
kicad from a subdirectory then you use one local to that directory.

You install all the bits and libraries in that same directory and you never
get any crossover between the system version and your experimental.

John Eaton
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[jp charras]

Le 05/04/2018 à 18:41, Nick Østergaard a écrit :
> This is a complicated topic. But I guess we can clutter the config dir as 
> much as we want with
> version folders. Usually the user should not have the need to look here. I 
> guess you are correct,
> that most of the "non-issue" is because the fp-lib-table was only introduced 
> in v4 and has not had a
> new syntax introduced that is not read by a previous stable.

In V5 we can disable some libraries. Disabled libraries is not supported by V4


> 
> 2018-04-05 18:25 GMT+02:00 Seth Hillbrand  >:
> 
> If we are going to support multiple versions, on the developer side, we 
> should add a preference
> versioning to the user configuration directory.  Otherwise, fp-lib-table 
> will being either
> pointing to v4 or v5 footprints.  Likewise, there are a few preferences 
> that only exist in v5
> and will be lost when v4 saves the preference file.
> 
> To avoid cluttering the config directory, we could place the v5 
> configurations in a v5 sub
> directory.  Configurations would be preferentially loaded from the v5 
> directory with a fall-back
> to the v4 items if v5 items were not found.  Configurations would only be 
> saved to the v5 subdir.
> 
> If we want to support this, we should insert this code before rc2.  
> Thoughts?
> 
> -S
> 
> 2018-04-04 22:24 GMT-07:00 Strontium  >:
> 
> On 04/04/18 18:52, Jean-Samuel Reynaud wrote:
> 
> So my questions are:
> - Is it usefull ?
> 
> 
> Having both versions be able to be installed side by side is 
> immensely valuable for an end
> user, and the development of kicad, in my opinion.
> 
> The users can "USE" the stable version for their work.  They can also 
> test the Nightly and
> not worry about it messing with their work.  It should mean that 
> general users have a better
> chance to test the new version as it evolves, and they will feel more 
> involved, even if that
> involvement is only posting bugs.  They don't have to choose between 
> being on the bleeding
> edge, and being productive.
> 
> It would be equally useful (maybe even more useful) to have kicad V4 
> and V5 installed
> simultaneously as well.
> 
> Steven
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Nick Østergaard]

This is a complicated topic. But I guess we can clutter the config dir as
much as we want with version folders. Usually the user should not have the
need to look here. I guess you are correct, that most of the "non-issue" is
because the fp-lib-table was only introduced in v4 and has not had a new
syntax introduced that is not read by a previous stable.

2018-04-05 18:25 GMT+02:00 Seth Hillbrand :

> If we are going to support multiple versions, on the developer side, we
> should add a preference versioning to the user configuration directory.
> Otherwise, fp-lib-table will being either pointing to v4 or v5 footprints.
> Likewise, there are a few preferences that only exist in v5 and will be
> lost when v4 saves the preference file.
>
> To avoid cluttering the config directory, we could place the v5
> configurations in a v5 sub directory.  Configurations would be
> preferentially loaded from the v5 directory with a fall-back to the v4
> items if v5 items were not found.  Configurations would only be saved to
> the v5 subdir.
>
> If we want to support this, we should insert this code before rc2.
> Thoughts?
>
> -S
>
> 2018-04-04 22:24 GMT-07:00 Strontium :
>
>> On 04/04/18 18:52, Jean-Samuel Reynaud wrote:
>>
>>> So my questions are:
>>> - Is it usefull ?
>>>
>>
>> Having both versions be able to be installed side by side is immensely
>> valuable for an end user, and the development of kicad, in my opinion.
>>
>> The users can "USE" the stable version for their work.  They can also
>> test the Nightly and not worry about it messing with their work.  It should
>> mean that general users have a better chance to test the new version as it
>> evolves, and they will feel more involved, even if that involvement is only
>> posting bugs.  They don't have to choose between being on the bleeding
>> edge, and being productive.
>>
>> It would be equally useful (maybe even more useful) to have kicad V4 and
>> V5 installed simultaneously as well.
>>
>> Steven
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Seth Hillbrand]

If we are going to support multiple versions, on the developer side, we
should add a preference versioning to the user configuration directory.
Otherwise, fp-lib-table will being either pointing to v4 or v5 footprints.
Likewise, there are a few preferences that only exist in v5 and will be
lost when v4 saves the preference file.

To avoid cluttering the config directory, we could place the v5
configurations in a v5 sub directory.  Configurations would be
preferentially loaded from the v5 directory with a fall-back to the v4
items if v5 items were not found.  Configurations would only be saved to
the v5 subdir.

If we want to support this, we should insert this code before rc2.
Thoughts?

-S

2018-04-04 22:24 GMT-07:00 Strontium :

> On 04/04/18 18:52, Jean-Samuel Reynaud wrote:
>
>> So my questions are:
>> - Is it usefull ?
>>
>
> Having both versions be able to be installed side by side is immensely
> valuable for an end user, and the development of kicad, in my opinion.
>
> The users can "USE" the stable version for their work.  They can also test
> the Nightly and not worry about it messing with their work.  It should mean
> that general users have a better chance to test the new version as it
> evolves, and they will feel more involved, even if that involvement is only
> posting bugs.  They don't have to choose between being on the bleeding
> edge, and being productive.
>
> It would be equally useful (maybe even more useful) to have kicad V4 and
> V5 installed simultaneously as well.
>
> Steven
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

On 04/04/18 18:52, Jean-Samuel Reynaud wrote:

So my questions are:
- Is it usefull ?


Having both versions be able to be installed side by side is immensely 
valuable for an end user, and the development of kicad, in my opinion.


The users can "USE" the stable version for their work.  They can also 
test the Nightly and not worry about it messing with their work.  It 
should mean that general users have a better chance to test the new 
version as it evolves, and they will feel more involved, even if that 
involvement is only posting bugs.  They don't have to choose between 
being on the bleeding edge, and being productive.


It would be equally useful (maybe even more useful) to have kicad V4 and 
V5 installed simultaneously as well.


Steven



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Nick Østergaard]

You can just set a different XDG_CONFIG_HOME. I think this should be left
for the user to define. Usually I have seen no significant problems running
with the same config dir. This may of course not aleays be true.

Alternatively the nightly package can provide a wrapper script that sets
this to something else. Then the user can use this, or make their own, or
not use it at all depending on what the user is testing.

Den ons. 4. apr. 2018 14.27 skrev Eeli Kaikkonen :

> I can confirm that many users would appreciate the possibility to run
> several precompiled versions. It has come up in the user forums. Using a
> virtual machine for that purpose has been suggested as a solution, but it's
> not very convenient.
>
> One possible problem is the configuration compatibility. It might be a
> good idea to have a command line switch to use a different configuration
> files/directories so that the installations could be completely
> independent. Also the env variables may be a problem. Maybe they could be
> overriden with command line switches, too?
>
> Eeli Kaikkonen
>
>
> 2018-04-04 13:52 GMT+03:00 Jean-Samuel Reynaud :
>
>> Dear All,
>>
>>
>> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
>> requests about installing daily build packages in parallel with stable
>> version.
>> With next version (V5) I think it can be useful...
>> FreeCad provide this kind of feature and you are able to run both
>> version in parallel.
>>
>> For testing that I had created a dedicated PPA:
>> ppa:js-reynaud/kicad-dev-daily
>> (to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev-daily)
>>
>> Once added, you are able to install a new package "kicad-daily" that
>> won't conflict with existing "kicad" packages.
>> All files are installed on a separate folder and commands became
>> "something-daily". For example kicad-daily or pcbnew-daily...
>>
>> So my questions are:
>> - Is it usefull ?
>> - Is it a bad idea/stupid :( ?
>> - If you test it, are you able to find some limitations/bugs ?
>> - Perhaps to have is plainly functional some modifications are needed.
>> What modifications ?
>>
>>
>> For the moment, you can't run in same time two versions (or there are
>> some error messages...) anyway both are installed and easily "runnable"...
>>
>>
>> Please give your comments, feedbacks...
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Mitja Nemec]

There might be a conflict in the settings (V4 might not be able to parse V5 
settings)I've filed a bug addressing this (feature request): 
https://bugs.launchpad.net/kicad/+bug/1749659

Also using V5 libs can be problematic in V4. One great thing is that at least 
in the latest V4 (4.0.7) there is no need for system wide environment 
variables. Thus one can run V4 and V5 with different set of libraries and have 
KiCad variables (KISYSMOD, KISYS3DMOD, ...) point to different locations in V4 
and V5. So I would recommend for the installer (at least on Windows) to not set 
the environment variables by default as this is not needed anymore. Leave it to 
the user to set them up within the KiCad. But this is a different issue. 

On Wednesday, 4 April 2018, 14:27, Eeli Kaikkonen 
 wrote:
 

 I can confirm that many users would appreciate the possibility to run several 
precompiled versions. It has come up in the user forums. Using a virtual 
machine for that purpose has been suggested as a solution, but it's not very 
convenient.

One possible problem is the configuration compatibility. It might be a good 
idea to have a command line switch to use a different configuration 
files/directories so that the installations could be completely independent. 
Also the env variables may be a problem. Maybe they could be overriden with 
command line switches, too?

Eeli Kaikkonen


2018-04-04 13:52 GMT+03:00 Jean-Samuel Reynaud :

Dear All,


Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
requests about installing daily build packages in parallel with stable
version.
With next version (V5) I think it can be useful...
FreeCad provide this kind of feature and you are able to run both
version in parallel.

For testing that I had created a dedicated PPA:
ppa:js-reynaud/kicad-dev-daily
(to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev- daily)

Once added, you are able to install a new package "kicad-daily" that
won't conflict with existing "kicad" packages.
All files are installed on a separate folder and commands became
"something-daily". For example kicad-daily or pcbnew-daily...

So my questions are:
- Is it usefull ?
- Is it a bad idea/stupid :( ?
- If you test it, are you able to find some limitations/bugs ?
- Perhaps to have is plainly functional some modifications are needed.
What modifications ?


For the moment, you can't run in same time two versions (or there are
some error messages...) anyway both are installed and easily "runnable"...


Please give your comments, feedbacks...

__ _
Mailing list: https://launchpad.net/~kicad- developers
Post to     : kicad-developers@lists. launchpad.net
Unsubscribe : https://launchpad.net/~kicad- developers
More help   : https://help.launchpad.net/ ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to    : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help  : https://help.launchpad.net/ListHelp


   ___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Eeli Kaikkonen]

I can confirm that many users would appreciate the possibility to run
several precompiled versions. It has come up in the user forums. Using a
virtual machine for that purpose has been suggested as a solution, but it's
not very convenient.

One possible problem is the configuration compatibility. It might be a good
idea to have a command line switch to use a different configuration
files/directories so that the installations could be completely
independent. Also the env variables may be a problem. Maybe they could be
overriden with command line switches, too?

Eeli Kaikkonen


2018-04-04 13:52 GMT+03:00 Jean-Samuel Reynaud :

> Dear All,
>
>
> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
> requests about installing daily build packages in parallel with stable
> version.
> With next version (V5) I think it can be useful...
> FreeCad provide this kind of feature and you are able to run both
> version in parallel.
>
> For testing that I had created a dedicated PPA:
> ppa:js-reynaud/kicad-dev-daily
> (to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev-daily)
>
> Once added, you are able to install a new package "kicad-daily" that
> won't conflict with existing "kicad" packages.
> All files are installed on a separate folder and commands became
> "something-daily". For example kicad-daily or pcbnew-daily...
>
> So my questions are:
> - Is it usefull ?
> - Is it a bad idea/stupid :( ?
> - If you test it, are you able to find some limitations/bugs ?
> - Perhaps to have is plainly functional some modifications are needed.
> What modifications ?
>
>
> For the moment, you can't run in same time two versions (or there are
> some error messages...) anyway both are installed and easily "runnable"...
>
>
> Please give your comments, feedbacks...
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Jean-Samuel Reynaud]

> 
> If you think the package is ready to be tested by a wider group, how
> about announcing it on the kicad.info forum [1]? If you do not have an
> account there, I can post a notice there for you.

Thanks. I think I will post a message in few days if I collect more
comments. As Nick say, I think I will change the name of he ppa to
"something nightly"




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Jean-Samuel Reynaud]

> 
> No, but I may personally prefer the term nightly over daily to be
> consistent with the terminology we have been using for quite some time.
>  
Ok, I will change that before communicating...

> 
> - If you test it, are you able to find some limitations/bugs ?
> 
> 
> I am not sure how you implemented this. I assume you have scripting
> enabled in both builds. You need to make sure that you are using the
> correct pcbnew python module that matches the version of kicad that you
> like to run such that it won't explode.
Yes, it's based on script helpers.

> 
> What error message? The generic, you are already running another
> instance of kicad or whatever it says? I think that can be ignored safely.
Yes, this is this error I speak. I don't know if there are side effects.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Nick Østergaard]

2018-04-04 12:52 GMT+02:00 Jean-Samuel Reynaud :

> Dear All,
>
>
> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
> requests about installing daily build packages in parallel with stable
> version.
> With next version (V5) I think it can be useful...
> FreeCad provide this kind of feature and you are able to run both
> version in parallel.
>
> For testing that I had created a dedicated PPA:
> ppa:js-reynaud/kicad-dev-daily
> (to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev-daily)
>
> Once added, you are able to install a new package "kicad-daily" that
> won't conflict with existing "kicad" packages.
> All files are installed on a separate folder and commands became
> "something-daily". For example kicad-daily or pcbnew-daily...
>
> So my questions are:
> - Is it usefull ?
>

Yes.


> - Is it a bad idea/stupid :( ?
>

No, but I may personally prefer the term nightly over daily to be
consistent with the terminology we have been using for quite some time.


> - If you test it, are you able to find some limitations/bugs ?
>

I am not sure how you implemented this. I assume you have scripting enabled
in both builds. You need to make sure that you are using the correct pcbnew
python module that matches the version of kicad that you like to run such
that it won't explode.


> - Perhaps to have is plainly functional some modifications are needed.
> What modifications ?
>
>
> For the moment, you can't run in same time two versions (or there are
> some error messages...) anyway both are installed and easily "runnable"...
>
>
What error message? The generic, you are already running another instance
of kicad or whatever it says? I think that can be ignored safely.


>
> Please give your comments, feedbacks...
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Maciej Sumiński]

Hi Jean-Samuel,

I suppose most people on the dev mailing list compile KiCad themselves,
but I am pretty sure the users would appreciate the possibility of
having two KiCad versions installed.

If you think the package is ready to be tested by a wider group, how
about announcing it on the kicad.info forum [1]? If you do not have an
account there, I can post a notice there for you.

Regards,
Orson

1. https://forum.kicad.info/

On 04/04/2018 12:52 PM, Jean-Samuel Reynaud wrote:
> Dear All,
> 
> 
> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
> requests about installing daily build packages in parallel with stable
> version.
> With next version (V5) I think it can be useful...
> FreeCad provide this kind of feature and you are able to run both
> version in parallel.
> 
> For testing that I had created a dedicated PPA:
> ppa:js-reynaud/kicad-dev-daily
> (to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev-daily)
> 
> Once added, you are able to install a new package "kicad-daily" that
> won't conflict with existing "kicad" packages.
> All files are installed on a separate folder and commands became
> "something-daily". For example kicad-daily or pcbnew-daily...
> 
> So my questions are:
> - Is it usefull ?
> - Is it a bad idea/stupid :( ?
> - If you test it, are you able to find some limitations/bugs ?
> - Perhaps to have is plainly functional some modifications are needed.
> What modifications ?
> 
> 
> For the moment, you can't run in same time two versions (or there are
> some error messages...) anyway both are installed and easily "runnable"...
> 
> 
> Please give your comments, feedbacks...
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp