[Kicad-developers] Why are courtyard rules not saved in the board?

[Jeff Young]

Not the courtyard graphics, but rather the require-courtyards and 
no-overlapping-courtyard settings?
___
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

[Kicad-developers] Jenkins build is back to normal : kicad-qa #3930

[Miguel Angel Ajo]

See 


___
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 ???

[Kicad-developers] Build failed in Jenkins: kicad-qa #3929

[Miguel Angel Ajo]

See 

Changes:

[tomasz.wlostowski] pcbnew: refresh message panel while drawing & editing 
graphical lines,

--
[...truncated 1.12 KB...]
 > git rev-list --no-walk 58c27398cb06265490b5288f1bc80470b75ad111 # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins2537955808624792356.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10+deb8u1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ grep -q ^MAKEJOBS=
+ env
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  0%] [  0%] Built target page_layout_lexer_source_files
Generating version string header
[  0%] Built target idf3
-- Using Git to determine build version string.
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  0%] Built target netlist_lexer_source_files
[  0%] [  0%] [  0%] Built target lib_table_lexer_source_files
-- Writing 
 file with 
version: (5.0.0-rc2-dev-423-g4e99b0d)
Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o
[  0%] Building CXX object common/CMakeFiles/gal.dir/basic_gal.cpp.o
[  0%] Built target version_header
Building CXX object common/CMakeFiles/gal.dir/origin_viewitem.cpp.o
[  0%] Building CXX object common/CMakeFiles/gal.dir/painter.cpp.o
In file included from 
:34:0,
 from 
:35,
 from 
:37,
 from 
:35:
:359:23: error: extra 
qualification not allowed [-fpermissive]
 template<> struct std::less
   ^
:360:5: error: 
explicit specialization of non-template ‘std::’
 {
 ^
:359:28: error: an 
anonymous struct cannot have function members
 template<> struct std::less
^
:362:5: error: 
abstract declarator ‘std::’ used as declaration
 };
 ^
In file included from 
:34:0,
 from 
:35,
 from 
:34,
 from 
:27:
:359:23: error: extra 
qualification not allowed [-fpermissive]
 template<> struct std::less
   ^
:360:5: error: 
explicit specialization of non-template ‘std::’
 {
 ^
:359:28: error: an 
anonymous struct cannot have function members
 template<> struct std::less
^
:362:5: error: 
abstract declarator ‘std::’ used as declaration
 };
 ^
common/CMakeFiles/gal.dir/build.make:54: recipe for target 
'common/CMakeFiles/gal.dir/basic_gal.cpp.o' failed
make[3]: *** [common/CMakeFiles/gal.dir/basic_gal.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs

[Kicad-developers] Build failed in Jenkins: kicad-qa #3928

[Miguel Angel Ajo]

See 

Changes:

[Maciej Suminski] Added std::less specialization for wxPoint

[Maciej Suminski] Eagle SCH import: improved implicit connections resolution

--
Started by an SCM change
Building remotely on debian8 (clang gcc linux) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://github.com/KiCad/kicad-source-mirror.git # timeout=10
Fetching upstream changes from https://github.com/KiCad/kicad-source-mirror.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/KiCad/kicad-source-mirror.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 58c27398cb06265490b5288f1bc80470b75ad111 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 58c27398cb06265490b5288f1bc80470b75ad111
Commit message: "Eagle SCH import: improved implicit connections resolution"
 > git rev-list --no-walk f42ca89bb4d179560e16b6d259f6dfd21c31a1f4 # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins3443021203210436960.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10+deb8u1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ grep -q ^MAKEJOBS=
+ env
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  0%] [  0%] [  0%] Built target page_layout_lexer_source_files
Built target idf3
Generating version string header
-- Using Git to determine build version string.
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  0%] Built target lib_table_lexer_source_files
[  0%] Built target netlist_lexer_source_files
-- Writing 
 file with 
version: (5.0.0-rc2-dev-422-g58c2739)
[  0%] Built target version_header
[  0%] Built target pcb_lexer_source_files
[  2%] Built target kicad_3dsg
[  2%] Built target pcb_plot_lexer_source_files
[  2%] Built target lib_dxf
[  2%] [ 46%] Built target bitmaps
Built target specctra_lexer_source_files
Scanning dependencies of target gal
[ 46%] [ 46%] Scanning dependencies of target polygon
Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o
Building CXX object common/CMakeFiles/gal.dir/basic_gal.cpp.o
[ 46%] Building CXX object 
polygon/CMakeFiles/polygon.dir/math_for_graphics.cpp.o
Scanning dependencies of target pcbcommon
[ 46%] Building CXX object common/CMakeFiles/pcbcommon.dir/base_screen.cpp.o
In file included from 
:34:0,
 from 
:35,
 from 
:37,
 from 
:35:
:359:23: error: extra 
qualification not allowed [-fpermissive]
 template<> struct std::less
   ^
:360:5: error: 
explicit specialization of non-template ‘std::’
 {
 ^
:359:28: error: an 
anonymous struct cannot have function members
 template<> struct std::less
^

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