KiCad

4.0.0 RC1 cannot find help

Bug #1496049 reported by Brian Sidebotham
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Undecided
Brian Sidebotham
4.0
Fix Released
Undecided
Brian Sidebotham

Bug Description

On Windows the 4.0.0 RC1 install cannot find it's own help.

The help is at C:\Program Files\KiCad\share\doc\kicad\help\en\kicad.pdf

The searched paths are like this:

Path
C:\msys64\mingw64
C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad

It looks like a two-fold problem. The packaging is putting the docs
under share\doc... where I guess it should be share\kicad\doc along
with everything else shared for KiCad.

Secondly the paths being search by the program include
share\kicad\template... which appears wrong. I'd expect it to be
\share\kicad\doc...

The version information:

Application: kicad
Version: 4.0.0-rc1-stable release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

Revision history for this message
Wayne Stambaugh (stambaughw) wrote : Re: [Bug 1496049] [NEW] 4.0.0 RC1 cannot find help
Download full text (3.9 KiB)

Hmmm? Where is "template" coming from? I don't see it being added to
the help SEARCH_STACK path list.

On 9/15/2015 12:23 PM, Brian Sidebotham wrote:
> Public bug reported:
>
> On Windows the 4.0.0 RC1 install cannot find it's own help.
>
> The help is at C:\Program Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>
> The searched paths are like this:
>
> Path
> C:\msys64\mingw64
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
>
> It looks like a two-fold problem. The packaging is putting the docs
> under share\doc... where I guess it should be share\kicad\doc along
> with everything else shared for KiCad.
>
> Secondly the paths being search by the program include
> share\kicad\template... which appears wrong. I'd expect it to be
> \share\kicad\doc...
>
> The version information:
>
> Application: kicad
> Version: 4.0.0-rc1-stable release build
> wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
> Platform: Windows 7 (build 7601, Serv...

Read more...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :

kicad/kicad.cpp:133 ( https://github.com/KiCad/kicad-source-mirror/blob/master/kicad/kicad.cpp#L134 )

Looks like there we have to also add in the missing links because KiCad is not a KiFace and therefore setSearchPaths() in common/kiface_i.cpp isn't used here. Although that looks wrong too because I don't see any doc or help subdir added for either PCB or SCH.

I'll investigate and fix.

I think we should ratify the directories a bit and make sure under Linux and Windows the help is under ./share/doc/kicad/help/ does that sound reasonable? because at the moment they're in an ever-so-slightly different structure to each other. This change would basically align Windows with Linux, so Linux stays the same and Windows aligns with it.

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote : Re: [Bug 1496049] Re: 4.0.0 RC1 cannot find help
Download full text (4.8 KiB)

Ah, sorry ignore that first but where pcb and sch look wrong too because
that's obviously not where the doc and help directories are added to the
search path.
On 15 Sep 2015 22:00, "Brian Sidebotham" <email address hidden> wrote:

> kicad/kicad.cpp:133 ( https://github.com/KiCad/kicad-source-
> mirror/blob/master/kicad/kicad.cpp#L134 )
>
> Looks like there we have to also add in the missing links because KiCad
> is not a KiFace and therefore setSearchPaths() in common/kiface_i.cpp
> isn't used here. Although that looks wrong too because I don't see any
> doc or help subdir added for either PCB or SCH.
>
> I'll investigate and fix.
>
> I think we should ratify the directories a bit and make sure under Linux
> and Windows the help is under ./share/doc/kicad/help/ does that sound
> reasonable? because at the moment they're in an ever-so-slightly
> different structure to each other. This change would basically align
> Windows with Linux, so Linux stays the same and Windows aligns with it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1496049
>
> Title:
> 4.0.0 RC1 cannot find help
>
> Status in KiCad:
> New
> Status in KiCad 4.0 series:
> New
>
> Bug description:
> On Windows the 4.0.0 RC1 install cannot find it's own help.
>
> The help is at C:\Program
> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>
> The searched paths are like this:
>
> Path
> C:\msys64\mingw64
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program...

Read more...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :

I'll build and test a fix tonight. Takes ages to build and test changes on Windows!

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

@Brian, I've been playing around with this on my system and I'm not
seeing this issue as long as the pdf files are installed in
$CMAKE_INSTALL_PREFIX/share/doc/kicad/help/XX_XX where XX_XX are the
locale. All of this was done with the legacy kicad-doc repo so maybe
that's why it still works for me. One thing I did notice in the new
documentation source on github is there does not appear to be an install
macro called to be able to run `make install`. Is the case or am I
missing something?

On 9/16/2015 4:16 AM, Brian Sidebotham wrote:
> I'll build and test a fix tonight. Takes ages to build and test changes
> on Windows!
>

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :
Download full text (4.7 KiB)

Perhaps this is just purely a packaging issue then. I will so some
testing tonight by moving the docs. I didn't bother because the path
didn't appear to get searched.

On 16 September 2015 at 15:08, Wayne Stambaugh
<email address hidden> wrote:
> @Brian, I've been playing around with this on my system and I'm not
> seeing this issue as long as the pdf files are installed in
> $CMAKE_INSTALL_PREFIX/share/doc/kicad/help/XX_XX where XX_XX are the
> locale. All of this was done with the legacy kicad-doc repo so maybe
> that's why it still works for me. One thing I did notice in the new
> documentation source on github is there does not appear to be an install
> macro called to be able to run `make install`. Is the case or am I
> missing something?
>
> On 9/16/2015 4:16 AM, Brian Sidebotham wrote:
>> I'll build and test a fix tonight. Takes ages to build and test changes
>> on Windows!
>>
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1496049
>
> Title:
> 4.0.0 RC1 cannot find help
>
> Status in KiCad:
> New
> Status in KiCad 4.0 series:
> New
>
> Bug description:
> On Windows the 4.0.0 RC1 install cannot find it's own help.
>
> The help is at C:\Program
> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>
> The searched paths are like this:
>
> Path
> C:\msys64\mingw64
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\d...

Read more...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (6.5 KiB)

I've taken a closer look at the list of paths you posted and something
is very wrong here. All of the possible sub-paths listed in the subdirs
wxArrayString defined in the SearchHelpFileFullPath() function are not
in your list of paths. Below is this what my msys2/mingw64 build
generates after adding some debugging output to the
FindFileInSearchPaths() function which looks correct.

Checking SEARCH_STACK for kicad in paths:
    C:\msys64\mingw64\doc\help\en_US\.
    C:\msys64\mingw64\share\kicad\template\doc\help\en_US\.
    C:\msys64\mingw64\doc\help\en_US\.
    C:\msys64\mingw64\share\kicad\template\doc\help\en_US\.
    C:\msys64\mingw64\share\doc\kicad\help\en_US\.
    C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en_US\.
    C:\msys64\mingw64\share\doc\kicad\help\en_US\.
    C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en_US\.
    C:\msys64\mingw64\doc\help\en\.
    C:\msys64\mingw64\share\kicad\template\doc\help\en\.
    C:\msys64\mingw64\doc\help\en\.
    C:\msys64\mingw64\share\kicad\template\doc\help\en\.
    C:\msys64\mingw64\share\doc\kicad\help\en\.
    C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.
    C:\msys64\mingw64\share\doc\kicad\help\en\.
    C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.
    C:\msys64\mingw64\doc\help\en\.
    C:\msys64\mingw64\share\kicad\template\doc\help\en\.
    C:\msys64\mingw64\doc\help\en\.
    C:\msys64\mingw64\share\kicad\template\doc\help\en\.
    C:\msys64\mingw64\share\doc\kicad\help\en\.
    C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.
    C:\msys64\mingw64\share\doc\kicad\help\en\.
    C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.

On 9/16/2015 11:28 AM, Brian Sidebotham wrote:
> Perhaps this is just purely a packaging issue then. I will so some
> testing tonight by moving the docs. I didn't bother because the path
> didn't appear to get searched.
>
> On 16 September 2015 at 15:08, Wayne Stambaugh
> <email address hidden> wrote:
>> @Brian, I've been playing around with this on my system and I'm not
>> seeing this issue as long as the pdf files are installed in
>> $CMAKE_INSTALL_PREFIX/share/doc/kicad/help/XX_XX where XX_XX are the
>> locale. All of this was done with the legacy kicad-doc repo so maybe
>> that's why it still works for me. One thing I did notice in the new
>> documentation source on github is there does not appear to be an install
>> macro called to be able to run `make install`. Is the case or am I
>> missing something?
>>
>> On 9/16/2015 4:16 AM, Brian Sidebotham wrote:
>>> I'll build and test a fix tonight. Takes ages to build and test changes
>>> on Windows!
>>>
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1496049
>>
>> Title:
>> 4.0.0 RC1 cannot find help
>>
>> Status in KiCad:
>> New
>> Status in KiCad 4.0 series:
>> New
>>
>> Bug description:
>> On Windows the 4.0.0 RC1 install cannot find it's own help.
>>
>> The help is at C:\Program
>> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>>
>> The searched paths are like this:
>>
>> Path
>> C:\msys64\mingw64...

Read more...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :
Download full text (12.0 KiB)

But what happens when you install 4.0.0-RC1? That's the problem here,
or more importantly when you install 4.0.0-RC1 and don't have the
C:\msys64\mingw64 directory.

I guess everything you have has successfully keyed off of
${CMAKE_INSTALL_PREFIX}. In the Windows 4.0.0-RC1 package that is set
to c:\msys64\mingw64 - which doesn't exist on my Windows 10 machine.

For example, if I create the C:\msys64\mingw64 directory the correct
set of folders is searched under that directory. That's great if you
can specify the installation folder at compile-time, but that's
obviously not possible when using a Windows installer, the installer
sets the installation path. You must use relative paths from the exe
to be sure you're searching in the right place IMO, but we appear to
be guessing ( There's comments through this code that use the word
guess! ) as to where the help files are...

It's crazy that a program installed in C:\Program Files\KiCad\bin
searches for its help files first and foremost under
c:\msys64\mingw64, who is expecting that? Why are we searching there
at all in a windows install? Perhaps that's just a packaging thing
again. It's so easy to search relative to the current binary, I just
don't understand why it's been complicated beyond belief to find a
help file....

Can we at least have the most important search as relative to the
current binary's dir?

On 16 September 2015 at 19:32, Wayne Stambaugh
<email address hidden> wrote:
> I've taken a closer look at the list of paths you posted and something
> is very wrong here. All of the possible sub-paths listed in the subdirs
> wxArrayString defined in the SearchHelpFileFullPath() function are not
> in your list of paths. Below is this what my msys2/mingw64 build
> generates after adding some debugging output to the
> FindFileInSearchPaths() function which looks correct.
>
> Checking SEARCH_STACK for kicad in paths:
> C:\msys64\mingw64\doc\help\en_US\.
> C:\msys64\mingw64\share\kicad\template\doc\help\en_US\.
> C:\msys64\mingw64\doc\help\en_US\.
> C:\msys64\mingw64\share\kicad\template\doc\help\en_US\.
> C:\msys64\mingw64\share\doc\kicad\help\en_US\.
> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en_US\.
> C:\msys64\mingw64\share\doc\kicad\help\en_US\.
> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en_US\.
> C:\msys64\mingw64\doc\help\en\.
> C:\msys64\mingw64\share\kicad\template\doc\help\en\.
> C:\msys64\mingw64\doc\help\en\.
> C:\msys64\mingw64\share\kicad\template\doc\help\en\.
> C:\msys64\mingw64\share\doc\kicad\help\en\.
> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.
> C:\msys64\mingw64\share\doc\kicad\help\en\.
> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.
> C:\msys64\mingw64\doc\help\en\.
> C:\msys64\mingw64\share\kicad\template\doc\help\en\.
> C:\msys64\mingw64\doc\help\en\.
> C:\msys64\mingw64\share\kicad\template\doc\help\en\.
> C:\msys64\mingw64\share\doc\kicad\help\en\.
> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en\.
> C:\msys64\mingw64\share\doc\kicad\help\en\.
> C:\msys64\mingw64\share\ki...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (12.7 KiB)

Did you set -DDEFAULT_INSTALL_PATH=c:\Program Files\KiCad when you
configured your build? DEFAULT_INSTALL_PATH was add a while ago to
allow for decoupling the build install path versus the installer package
install path. By default, DEFAULT_INSTALL_PATH=CMAKE_PREFIX_PATH if you
don't specify it. The the case of the windows installer, you should set
DEFAULT_INSTALL_PATH to the default install path.

On 9/16/2015 4:47 PM, Brian Sidebotham wrote:
> But what happens when you install 4.0.0-RC1? That's the problem here,
> or more importantly when you install 4.0.0-RC1 and don't have the
> C:\msys64\mingw64 directory.
>
> I guess everything you have has successfully keyed off of
> ${CMAKE_INSTALL_PREFIX}. In the Windows 4.0.0-RC1 package that is set
> to c:\msys64\mingw64 - which doesn't exist on my Windows 10 machine.
>
> For example, if I create the C:\msys64\mingw64 directory the correct
> set of folders is searched under that directory. That's great if you
> can specify the installation folder at compile-time, but that's
> obviously not possible when using a Windows installer, the installer
> sets the installation path. You must use relative paths from the exe
> to be sure you're searching in the right place IMO, but we appear to
> be guessing ( There's comments through this code that use the word
> guess! ) as to where the help files are...
>
> It's crazy that a program installed in C:\Program Files\KiCad\bin
> searches for its help files first and foremost under
> c:\msys64\mingw64, who is expecting that? Why are we searching there
> at all in a windows install? Perhaps that's just a packaging thing
> again. It's so easy to search relative to the current binary, I just
> don't understand why it's been complicated beyond belief to find a
> help file....
>
> Can we at least have the most important search as relative to the
> current binary's dir?
>
> On 16 September 2015 at 19:32, Wayne Stambaugh
> <email address hidden> wrote:
>> I've taken a closer look at the list of paths you posted and something
>> is very wrong here. All of the possible sub-paths listed in the subdirs
>> wxArrayString defined in the SearchHelpFileFullPath() function are not
>> in your list of paths. Below is this what my msys2/mingw64 build
>> generates after adding some debugging output to the
>> FindFileInSearchPaths() function which looks correct.
>>
>> Checking SEARCH_STACK for kicad in paths:
>> C:\msys64\mingw64\doc\help\en_US\.
>> C:\msys64\mingw64\share\kicad\template\doc\help\en_US\.
>> C:\msys64\mingw64\doc\help\en_US\.
>> C:\msys64\mingw64\share\kicad\template\doc\help\en_US\.
>> C:\msys64\mingw64\share\doc\kicad\help\en_US\.
>> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en_US\.
>> C:\msys64\mingw64\share\doc\kicad\help\en_US\.
>> C:\msys64\mingw64\share\kicad\template\share\doc\kicad\help\en_US\.
>> C:\msys64\mingw64\doc\help\en\.
>> C:\msys64\mingw64\share\kicad\template\doc\help\en\.
>> C:\msys64\mingw64\doc\help\en\.
>> C:\msys64\mingw64\share\kicad\template\doc\help\en\.
>> C:\msys64\mingw64\share\doc\kicad\help\en\.
>> C:\msys64\mingw64\share\kicad\template\share\doc\k...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :
Download full text (17.8 KiB)

I installed 4.0.0-RC1, like a user. I didn't create the package, but
perhaps it was generated with KiCad-Winbuilder, I think Nick was
getting Winbuilder ready so it could create the KiCad Windows
installers. I've not been on Windows for some time now.

The simplest "quick" fix is to set an environment variable, KICAD to
the KiCad install path, i.e. if using the default install path:
"C:\Program Files\KiCad" then the help search works of course.

In the installer someone can pick another place to install KiCad, so
it's not really something you can set at all reliably at compile time.
However, a plaster over the problem at least gets it working for
people. Setting the KICAD env var upon install to the installation
path would be a fix that works at least. I don't think that should
affect the search paths for other things adversely will it?

On 16 September 2015 at 22:01, Wayne Stambaugh
<email address hidden> wrote:
> Did you set -DDEFAULT_INSTALL_PATH=c:\Program Files\KiCad when you
> configured your build? DEFAULT_INSTALL_PATH was add a while ago to
> allow for decoupling the build install path versus the installer package
> install path. By default, DEFAULT_INSTALL_PATH=CMAKE_PREFIX_PATH if you
> don't specify it. The the case of the windows installer, you should set
> DEFAULT_INSTALL_PATH to the default install path.
>
> On 9/16/2015 4:47 PM, Brian Sidebotham wrote:
>> But what happens when you install 4.0.0-RC1? That's the problem here,
>> or more importantly when you install 4.0.0-RC1 and don't have the
>> C:\msys64\mingw64 directory.
>>
>> I guess everything you have has successfully keyed off of
>> ${CMAKE_INSTALL_PREFIX}. In the Windows 4.0.0-RC1 package that is set
>> to c:\msys64\mingw64 - which doesn't exist on my Windows 10 machine.
>>
>> For example, if I create the C:\msys64\mingw64 directory the correct
>> set of folders is searched under that directory. That's great if you
>> can specify the installation folder at compile-time, but that's
>> obviously not possible when using a Windows installer, the installer
>> sets the installation path. You must use relative paths from the exe
>> to be sure you're searching in the right place IMO, but we appear to
>> be guessing ( There's comments through this code that use the word
>> guess! ) as to where the help files are...
>>
>> It's crazy that a program installed in C:\Program Files\KiCad\bin
>> searches for its help files first and foremost under
>> c:\msys64\mingw64, who is expecting that? Why are we searching there
>> at all in a windows install? Perhaps that's just a packaging thing
>> again. It's so easy to search relative to the current binary, I just
>> don't understand why it's been complicated beyond belief to find a
>> help file....
>>
>> Can we at least have the most important search as relative to the
>> current binary's dir?
>>
>> On 16 September 2015 at 19:32, Wayne Stambaugh
>> <email address hidden> wrote:
>>> I've taken a closer look at the list of paths you posted and something
>>> is very wrong here. All of the possible sub-paths listed in the subdirs
>>> wxArrayString defined in the SearchHelpFileFullPath() function are not
>>> in your list of paths. ...

Revision history for this message
Nick Østergaard (nickoe) wrote :
Download full text (22.5 KiB)

The current option is -DDEFAULT_INSTALL_PATH=${MINGW_PREFIX} \

I guess that is not ideal. But my problem is indeed as Brian mentions,
the path can be changed by the user installing the application. This
is how every windows persion expects a windows installer to work.
Setting a static absolute path is not ideal.

This KICAD env var that Brian mentions, does this exist already? (I
have not looked at the search stack code)

2015-09-16 23:19 GMT+02:00 Brian Sidebotham <email address hidden>:
> I installed 4.0.0-RC1, like a user. I didn't create the package, but
> perhaps it was generated with KiCad-Winbuilder, I think Nick was
> getting Winbuilder ready so it could create the KiCad Windows
> installers. I've not been on Windows for some time now.
>
> The simplest "quick" fix is to set an environment variable, KICAD to
> the KiCad install path, i.e. if using the default install path:
> "C:\Program Files\KiCad" then the help search works of course.
>
> In the installer someone can pick another place to install KiCad, so
> it's not really something you can set at all reliably at compile time.
> However, a plaster over the problem at least gets it working for
> people. Setting the KICAD env var upon install to the installation
> path would be a fix that works at least. I don't think that should
> affect the search paths for other things adversely will it?
>
> On 16 September 2015 at 22:01, Wayne Stambaugh
> <email address hidden> wrote:
>> Did you set -DDEFAULT_INSTALL_PATH=c:\Program Files\KiCad when you
>> configured your build? DEFAULT_INSTALL_PATH was add a while ago to
>> allow for decoupling the build install path versus the installer package
>> install path. By default, DEFAULT_INSTALL_PATH=CMAKE_PREFIX_PATH if you
>> don't specify it. The the case of the windows installer, you should set
>> DEFAULT_INSTALL_PATH to the default install path.
>>
>> On 9/16/2015 4:47 PM, Brian Sidebotham wrote:
>>> But what happens when you install 4.0.0-RC1? That's the problem here,
>>> or more importantly when you install 4.0.0-RC1 and don't have the
>>> C:\msys64\mingw64 directory.
>>>
>>> I guess everything you have has successfully keyed off of
>>> ${CMAKE_INSTALL_PREFIX}. In the Windows 4.0.0-RC1 package that is set
>>> to c:\msys64\mingw64 - which doesn't exist on my Windows 10 machine.
>>>
>>> For example, if I create the C:\msys64\mingw64 directory the correct
>>> set of folders is searched under that directory. That's great if you
>>> can specify the installation folder at compile-time, but that's
>>> obviously not possible when using a Windows installer, the installer
>>> sets the installation path. You must use relative paths from the exe
>>> to be sure you're searching in the right place IMO, but we appear to
>>> be guessing ( There's comments through this code that use the word
>>> guess! ) as to where the help files are...
>>>
>>> It's crazy that a program installed in C:\Program Files\KiCad\bin
>>> searches for its help files first and foremost under
>>> c:\msys64\mingw64, who is expecting that? Why are we searching there
>>> at all in a windows install? Perhaps that's just a packaging thing
>>> again. It's so easy to search relat...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :
Download full text (27.2 KiB)

Hi Nick, yes already exists:
https://github.com/KiCad/kicad-source-mirror/blob/master/common/systemdirsappend.cpp#L52

It's the first path used in the search, so the installer can set it
and fix this problem without changing the current code.

On 16 September 2015 at 22:30, Nick Østergaard
<email address hidden> wrote:
> The current option is -DDEFAULT_INSTALL_PATH=${MINGW_PREFIX} \
>
> I guess that is not ideal. But my problem is indeed as Brian mentions,
> the path can be changed by the user installing the application. This
> is how every windows persion expects a windows installer to work.
> Setting a static absolute path is not ideal.
>
> This KICAD env var that Brian mentions, does this exist already? (I
> have not looked at the search stack code)
>
> 2015-09-16 23:19 GMT+02:00 Brian Sidebotham <email address hidden>:
>> I installed 4.0.0-RC1, like a user. I didn't create the package, but
>> perhaps it was generated with KiCad-Winbuilder, I think Nick was
>> getting Winbuilder ready so it could create the KiCad Windows
>> installers. I've not been on Windows for some time now.
>>
>> The simplest "quick" fix is to set an environment variable, KICAD to
>> the KiCad install path, i.e. if using the default install path:
>> "C:\Program Files\KiCad" then the help search works of course.
>>
>> In the installer someone can pick another place to install KiCad, so
>> it's not really something you can set at all reliably at compile time.
>> However, a plaster over the problem at least gets it working for
>> people. Setting the KICAD env var upon install to the installation
>> path would be a fix that works at least. I don't think that should
>> affect the search paths for other things adversely will it?
>>
>> On 16 September 2015 at 22:01, Wayne Stambaugh
>> <email address hidden> wrote:
>>> Did you set -DDEFAULT_INSTALL_PATH=c:\Program Files\KiCad when you
>>> configured your build? DEFAULT_INSTALL_PATH was add a while ago to
>>> allow for decoupling the build install path versus the installer package
>>> install path. By default, DEFAULT_INSTALL_PATH=CMAKE_PREFIX_PATH if you
>>> don't specify it. The the case of the windows installer, you should set
>>> DEFAULT_INSTALL_PATH to the default install path.
>>>
>>> On 9/16/2015 4:47 PM, Brian Sidebotham wrote:
>>>> But what happens when you install 4.0.0-RC1? That's the problem here,
>>>> or more importantly when you install 4.0.0-RC1 and don't have the
>>>> C:\msys64\mingw64 directory.
>>>>
>>>> I guess everything you have has successfully keyed off of
>>>> ${CMAKE_INSTALL_PREFIX}. In the Windows 4.0.0-RC1 package that is set
>>>> to c:\msys64\mingw64 - which doesn't exist on my Windows 10 machine.
>>>>
>>>> For example, if I create the C:\msys64\mingw64 directory the correct
>>>> set of folders is searched under that directory. That's great if you
>>>> can specify the installation folder at compile-time, but that's
>>>> obviously not possible when using a Windows installer, the installer
>>>> sets the installation path. You must use relative paths from the exe
>>>> to be sure you're searching in the right place IMO, but we appear to
>>>> be guessing ( There's comments through th...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (23.8 KiB)

That's the problem. @Nick, are you using the msys2 PKGBUILD for
mingw32/mingw64? If so, there is another issue. The PKGBUILD creates a
branch of the legacy doc mirrored on github. This documentation is no
longer valid. AFAIK, there is no way to build the new asciidoc
documentation on msys2 without some major work. One option would be to
copy the nightly documentation files from the auto builder at
http://ci.kicad-pcb.org/job/kicad-doc-testing-pull-request/lastSuccessfulBuild/artifact/build-cmake/.
 This would save us from having to get all of the asciidoc dependencies
to build and install on msys to generate the documentation from source.

On 9/16/2015 5:30 PM, Nick Østergaard wrote:
> The current option is -DDEFAULT_INSTALL_PATH=${MINGW_PREFIX} \
>
> I guess that is not ideal. But my problem is indeed as Brian mentions,
> the path can be changed by the user installing the application. This
> is how every windows persion expects a windows installer to work.
> Setting a static absolute path is not ideal.
>
> This KICAD env var that Brian mentions, does this exist already? (I
> have not looked at the search stack code)
>
> 2015-09-16 23:19 GMT+02:00 Brian Sidebotham <email address hidden>:
>> I installed 4.0.0-RC1, like a user. I didn't create the package, but
>> perhaps it was generated with KiCad-Winbuilder, I think Nick was
>> getting Winbuilder ready so it could create the KiCad Windows
>> installers. I've not been on Windows for some time now.
>>
>> The simplest "quick" fix is to set an environment variable, KICAD to
>> the KiCad install path, i.e. if using the default install path:
>> "C:\Program Files\KiCad" then the help search works of course.
>>
>> In the installer someone can pick another place to install KiCad, so
>> it's not really something you can set at all reliably at compile time.
>> However, a plaster over the problem at least gets it working for
>> people. Setting the KICAD env var upon install to the installation
>> path would be a fix that works at least. I don't think that should
>> affect the search paths for other things adversely will it?
>>
>> On 16 September 2015 at 22:01, Wayne Stambaugh
>> <email address hidden> wrote:
>>> Did you set -DDEFAULT_INSTALL_PATH=c:\Program Files\KiCad when you
>>> configured your build? DEFAULT_INSTALL_PATH was add a while ago to
>>> allow for decoupling the build install path versus the installer package
>>> install path. By default, DEFAULT_INSTALL_PATH=CMAKE_PREFIX_PATH if you
>>> don't specify it. The the case of the windows installer, you should set
>>> DEFAULT_INSTALL_PATH to the default install path.
>>>
>>> On 9/16/2015 4:47 PM, Brian Sidebotham wrote:
>>>> But what happens when you install 4.0.0-RC1? That's the problem here,
>>>> or more importantly when you install 4.0.0-RC1 and don't have the
>>>> C:\msys64\mingw64 directory.
>>>>
>>>> I guess everything you have has successfully keyed off of
>>>> ${CMAKE_INSTALL_PREFIX}. In the Windows 4.0.0-RC1 package that is set
>>>> to c:\msys64\mingw64 - which doesn't exist on my Windows 10 machine.
>>>>
>>>> For example, if I create the C:\msys64\mingw64 directory the correct
>>>> set of folders is searched unde...

Revision history for this message
Nick Østergaard (nickoe) wrote :
Download full text (28.4 KiB)

I am using a custom version, but I am intending to package the one
from http://docs.kicad-pcb.org/kicad-doc-unknown.tar.gz untill we get
the last translations ready for the non rc release.

2015-09-17 0:44 GMT+02:00 Wayne Stambaugh <email address hidden>:
> That's the problem. @Nick, are you using the msys2 PKGBUILD for
> mingw32/mingw64? If so, there is another issue. The PKGBUILD creates a
> branch of the legacy doc mirrored on github. This documentation is no
> longer valid. AFAIK, there is no way to build the new asciidoc
> documentation on msys2 without some major work. One option would be to
> copy the nightly documentation files from the auto builder at
> http://ci.kicad-pcb.org/job/kicad-doc-testing-pull-request/lastSuccessfulBuild/artifact/build-cmake/.
> This would save us from having to get all of the asciidoc dependencies
> to build and install on msys to generate the documentation from source.
>
> On 9/16/2015 5:30 PM, Nick Østergaard wrote:
>> The current option is -DDEFAULT_INSTALL_PATH=${MINGW_PREFIX} \
>>
>> I guess that is not ideal. But my problem is indeed as Brian mentions,
>> the path can be changed by the user installing the application. This
>> is how every windows persion expects a windows installer to work.
>> Setting a static absolute path is not ideal.
>>
>> This KICAD env var that Brian mentions, does this exist already? (I
>> have not looked at the search stack code)
>>
>> 2015-09-16 23:19 GMT+02:00 Brian Sidebotham <email address hidden>:
>>> I installed 4.0.0-RC1, like a user. I didn't create the package, but
>>> perhaps it was generated with KiCad-Winbuilder, I think Nick was
>>> getting Winbuilder ready so it could create the KiCad Windows
>>> installers. I've not been on Windows for some time now.
>>>
>>> The simplest "quick" fix is to set an environment variable, KICAD to
>>> the KiCad install path, i.e. if using the default install path:
>>> "C:\Program Files\KiCad" then the help search works of course.
>>>
>>> In the installer someone can pick another place to install KiCad, so
>>> it's not really something you can set at all reliably at compile time.
>>> However, a plaster over the problem at least gets it working for
>>> people. Setting the KICAD env var upon install to the installation
>>> path would be a fix that works at least. I don't think that should
>>> affect the search paths for other things adversely will it?
>>>
>>> On 16 September 2015 at 22:01, Wayne Stambaugh
>>> <email address hidden> wrote:
>>>> Did you set -DDEFAULT_INSTALL_PATH=c:\Program Files\KiCad when you
>>>> configured your build? DEFAULT_INSTALL_PATH was add a while ago to
>>>> allow for decoupling the build install path versus the installer package
>>>> install path. By default, DEFAULT_INSTALL_PATH=CMAKE_PREFIX_PATH if you
>>>> don't specify it. The the case of the windows installer, you should set
>>>> DEFAULT_INSTALL_PATH to the default install path.
>>>>
>>>> On 9/16/2015 4:47 PM, Brian Sidebotham wrote:
>>>>> But what happens when you install 4.0.0-RC1? That's the problem here,
>>>>> or more importantly when you install 4.0.0-RC1 and don't have the
>>>>> C:\msys64\mingw64 directory.
>>>>>
>>>>> ...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (29.7 KiB)

I'm assuming that you are going to set DEFAULT_INSTALL_PATH so that if
the user installs in the default location in windows they will be able
to open the help files.

That being said, I may change the help path to an environment variable
where the default value should point to the correct path. The whole
search path idea is terrible. This way the user can change the
documentation path to whatever they want. I'll make it behave like all
of the other predefined environment variables so it can be overridden by
externally defined a path. Any thoughts on this?

On 9/16/2015 7:02 PM, Nick Østergaard wrote:
> I am using a custom version, but I am intending to package the one
> from http://docs.kicad-pcb.org/kicad-doc-unknown.tar.gz untill we get
> the last translations ready for the non rc release.
>
> 2015-09-17 0:44 GMT+02:00 Wayne Stambaugh <email address hidden>:
>> That's the problem. @Nick, are you using the msys2 PKGBUILD for
>> mingw32/mingw64? If so, there is another issue. The PKGBUILD creates a
>> branch of the legacy doc mirrored on github. This documentation is no
>> longer valid. AFAIK, there is no way to build the new asciidoc
>> documentation on msys2 without some major work. One option would be to
>> copy the nightly documentation files from the auto builder at
>> http://ci.kicad-pcb.org/job/kicad-doc-testing-pull-request/lastSuccessfulBuild/artifact/build-cmake/.
>> This would save us from having to get all of the asciidoc dependencies
>> to build and install on msys to generate the documentation from source.
>>
>> On 9/16/2015 5:30 PM, Nick Østergaard wrote:
>>> The current option is -DDEFAULT_INSTALL_PATH=${MINGW_PREFIX} \
>>>
>>> I guess that is not ideal. But my problem is indeed as Brian mentions,
>>> the path can be changed by the user installing the application. This
>>> is how every windows persion expects a windows installer to work.
>>> Setting a static absolute path is not ideal.
>>>
>>> This KICAD env var that Brian mentions, does this exist already? (I
>>> have not looked at the search stack code)
>>>
>>> 2015-09-16 23:19 GMT+02:00 Brian Sidebotham <email address hidden>:
>>>> I installed 4.0.0-RC1, like a user. I didn't create the package, but
>>>> perhaps it was generated with KiCad-Winbuilder, I think Nick was
>>>> getting Winbuilder ready so it could create the KiCad Windows
>>>> installers. I've not been on Windows for some time now.
>>>>
>>>> The simplest "quick" fix is to set an environment variable, KICAD to
>>>> the KiCad install path, i.e. if using the default install path:
>>>> "C:\Program Files\KiCad" then the help search works of course.
>>>>
>>>> In the installer someone can pick another place to install KiCad, so
>>>> it's not really something you can set at all reliably at compile time.
>>>> However, a plaster over the problem at least gets it working for
>>>> people. Setting the KICAD env var upon install to the installation
>>>> path would be a fix that works at least. I don't think that should
>>>> affect the search paths for other things adversely will it?
>>>>
>>>> On 16 September 2015 at 22:01, Wayne Stambaugh
>>>> <email address hidden> wrote:
>>>>> Did you set -DDEF...

Revision history for this message
jean-pierre charras (jp-charras) wrote :

I am thinking using an environment variable "like the other predefined environment variables" (I am guessing like KISYS3DMOD for instance, which can be set in Configuration Path dialog) is the best way.
Using DEFAULT_INSTALL_PATH to find the help files is not good (DEFAULT_INSTALL_PATH is not always the actual install path).
This is the best way because like KISYS3DMOD the doc path:
- Can be set to the actual path ( not known at build time ) by the user or the installer.
- Is clearly known in the dialog

Revision history for this message
Nick Østergaard (nickoe) wrote :
Download full text (34.5 KiB)

Why can't all variables be overridden by real environment variables? I
seems that not even KIGITHUB can be overridden, at least on windows,
and not even catched when no confs are present.

And even setting KICAD to C:\Program Files\KiCad does not work. Is
this broken on windows or? I used set KICAD=foo

2015-09-17 1:46 GMT+02:00 Wayne Stambaugh <email address hidden>:
> I'm assuming that you are going to set DEFAULT_INSTALL_PATH so that if
> the user installs in the default location in windows they will be able
> to open the help files.
>
> That being said, I may change the help path to an environment variable
> where the default value should point to the correct path. The whole
> search path idea is terrible. This way the user can change the
> documentation path to whatever they want. I'll make it behave like all
> of the other predefined environment variables so it can be overridden by
> externally defined a path. Any thoughts on this?
>
> On 9/16/2015 7:02 PM, Nick Østergaard wrote:
>> I am using a custom version, but I am intending to package the one
>> from http://docs.kicad-pcb.org/kicad-doc-unknown.tar.gz untill we get
>> the last translations ready for the non rc release.
>>
>> 2015-09-17 0:44 GMT+02:00 Wayne Stambaugh <email address hidden>:
>>> That's the problem. @Nick, are you using the msys2 PKGBUILD for
>>> mingw32/mingw64? If so, there is another issue. The PKGBUILD creates a
>>> branch of the legacy doc mirrored on github. This documentation is no
>>> longer valid. AFAIK, there is no way to build the new asciidoc
>>> documentation on msys2 without some major work. One option would be to
>>> copy the nightly documentation files from the auto builder at
>>> http://ci.kicad-pcb.org/job/kicad-doc-testing-pull-request/lastSuccessfulBuild/artifact/build-cmake/.
>>> This would save us from having to get all of the asciidoc dependencies
>>> to build and install on msys to generate the documentation from source.
>>>
>>> On 9/16/2015 5:30 PM, Nick Østergaard wrote:
>>>> The current option is -DDEFAULT_INSTALL_PATH=${MINGW_PREFIX} \
>>>>
>>>> I guess that is not ideal. But my problem is indeed as Brian mentions,
>>>> the path can be changed by the user installing the application. This
>>>> is how every windows persion expects a windows installer to work.
>>>> Setting a static absolute path is not ideal.
>>>>
>>>> This KICAD env var that Brian mentions, does this exist already? (I
>>>> have not looked at the search stack code)
>>>>
>>>> 2015-09-16 23:19 GMT+02:00 Brian Sidebotham <email address hidden>:
>>>>> I installed 4.0.0-RC1, like a user. I didn't create the package, but
>>>>> perhaps it was generated with KiCad-Winbuilder, I think Nick was
>>>>> getting Winbuilder ready so it could create the KiCad Windows
>>>>> installers. I've not been on Windows for some time now.
>>>>>
>>>>> The simplest "quick" fix is to set an environment variable, KICAD to
>>>>> the KiCad install path, i.e. if using the default install path:
>>>>> "C:\Program Files\KiCad" then the help search works of course.
>>>>>
>>>>> In the installer someone can pick another place to install KiCad, so
>>>>> it's not really something you ca...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

On 9/17/2015 2:17 AM, jean-pierre charras wrote:
> I am thinking using an environment variable "like the other predefined environment variables" (I am guessing like KISYS3DMOD for instance, which can be set in Configuration Path dialog) is the best way.

This is exactly what I was thinking. Using and environment variable
also gives the user/developer the flexibility to use any path.

> Using DEFAULT_INSTALL_PATH to find the help files is not good (DEFAULT_INSTALL_PATH is not always the actual install path).

This was dependent on the developer setting DEFAULT_INSTALL_PATH
correctly. It may have been wishful thinking on my part. It also
doesn't work on systems with installers that allow installation in a
user selected path that doesn't match the default path.

> This is the best way because like KISYS3DMOD the doc path:
> - Can be set to the actual path ( not known at build time ) by the user or the installer.
> - Is clearly known in the dialog
>

@Brian, do you want to take this on? If not, I should be able to knock
it out over the weekend.

Wayne

Revision history for this message
Nick Østergaard (nickoe) wrote :
Download full text (5.2 KiB)

Hi Wayne

I am still a bit confused here. Are the variables seen in the
footprint library table bottom and all the ones in the configure paths
dialog not supposed to be overridden by a system environment variable?
If so, it does not seem to work.

2015-09-17 14:20 GMT+02:00 Wayne Stambaugh <email address hidden>:
> On 9/17/2015 2:17 AM, jean-pierre charras wrote:
>> I am thinking using an environment variable "like the other predefined environment variables" (I am guessing like KISYS3DMOD for instance, which can be set in Configuration Path dialog) is the best way.
>
> This is exactly what I was thinking. Using and environment variable
> also gives the user/developer the flexibility to use any path.
>
>> Using DEFAULT_INSTALL_PATH to find the help files is not good
> (DEFAULT_INSTALL_PATH is not always the actual install path).
>
> This was dependent on the developer setting DEFAULT_INSTALL_PATH
> correctly. It may have been wishful thinking on my part. It also
> doesn't work on systems with installers that allow installation in a
> user selected path that doesn't match the default path.
>
>> This is the best way because like KISYS3DMOD the doc path:
>> - Can be set to the actual path ( not known at build time ) by the user or the installer.
>> - Is clearly known in the dialog
>>
>
> @Brian, do you want to take this on? If not, I should be able to knock
> it out over the weekend.
>
> Wayne
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1496049
>
> Title:
> 4.0.0 RC1 cannot find help
>
> Status in KiCad:
> New
> Status in KiCad 4.0 series:
> New
>
> Bug description:
> On Windows the 4.0.0 RC1 install cannot find it's own help.
>
> The help is at C:\Program
> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>
> The searched paths are like this:
>
> Path
> C:\msys64\mingw64
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program...

Read more...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (5.6 KiB)

Nick,

Not necessarily. The fp-lib-table dialog shows the paths that will be
substituted in the fp-lib-table plus a few others like KISYS3DMOD of
which I am not sure why.

Wayne

On 9/17/2015 1:41 PM, Nick Østergaard wrote:
> Hi Wayne
>
> I am still a bit confused here. Are the variables seen in the
> footprint library table bottom and all the ones in the configure paths
> dialog not supposed to be overridden by a system environment variable?
> If so, it does not seem to work.
>
> 2015-09-17 14:20 GMT+02:00 Wayne Stambaugh <email address hidden>:
>> On 9/17/2015 2:17 AM, jean-pierre charras wrote:
>>> I am thinking using an environment variable "like the other predefined environment variables" (I am guessing like KISYS3DMOD for instance, which can be set in Configuration Path dialog) is the best way.
>>
>> This is exactly what I was thinking. Using and environment variable
>> also gives the user/developer the flexibility to use any path.
>>
>>> Using DEFAULT_INSTALL_PATH to find the help files is not good
>> (DEFAULT_INSTALL_PATH is not always the actual install path).
>>
>> This was dependent on the developer setting DEFAULT_INSTALL_PATH
>> correctly. It may have been wishful thinking on my part. It also
>> doesn't work on systems with installers that allow installation in a
>> user selected path that doesn't match the default path.
>>
>>> This is the best way because like KISYS3DMOD the doc path:
>>> - Can be set to the actual path ( not known at build time ) by the user or the installer.
>>> - Is clearly known in the dialog
>>>
>>
>> @Brian, do you want to take this on? If not, I should be able to knock
>> it out over the weekend.
>>
>> Wayne
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1496049
>>
>> Title:
>> 4.0.0 RC1 cannot find help
>>
>> Status in KiCad:
>> New
>> Status in KiCad 4.0 series:
>> New
>>
>> Bug description:
>> On Windows the 4.0.0 RC1 install cannot find it's own help.
>>
>> The help is at C:\Program
>> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>>
>> The searched paths are like this:
>>
>> Path
>> C:\msys64\mingw64
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad...

Read more...

Revision history for this message
Nick Østergaard (nickoe) wrote :
Download full text (9.6 KiB)

Yes, and can't they be changed by a system env var?

2015-09-17 21:01 GMT+02:00 Wayne Stambaugh <email address hidden>:
> Nick,
>
> Not necessarily. The fp-lib-table dialog shows the paths that will be
> substituted in the fp-lib-table plus a few others like KISYS3DMOD of
> which I am not sure why.
>
> Wayne
>
> On 9/17/2015 1:41 PM, Nick Østergaard wrote:
>> Hi Wayne
>>
>> I am still a bit confused here. Are the variables seen in the
>> footprint library table bottom and all the ones in the configure paths
>> dialog not supposed to be overridden by a system environment variable?
>> If so, it does not seem to work.
>>
>> 2015-09-17 14:20 GMT+02:00 Wayne Stambaugh <email address hidden>:
>>> On 9/17/2015 2:17 AM, jean-pierre charras wrote:
>>>> I am thinking using an environment variable "like the other predefined environment variables" (I am guessing like KISYS3DMOD for instance, which can be set in Configuration Path dialog) is the best way.
>>>
>>> This is exactly what I was thinking. Using and environment variable
>>> also gives the user/developer the flexibility to use any path.
>>>
>>>> Using DEFAULT_INSTALL_PATH to find the help files is not good
>>> (DEFAULT_INSTALL_PATH is not always the actual install path).
>>>
>>> This was dependent on the developer setting DEFAULT_INSTALL_PATH
>>> correctly. It may have been wishful thinking on my part. It also
>>> doesn't work on systems with installers that allow installation in a
>>> user selected path that doesn't match the default path.
>>>
>>>> This is the best way because like KISYS3DMOD the doc path:
>>>> - Can be set to the actual path ( not known at build time ) by the user or the installer.
>>>> - Is clearly known in the dialog
>>>>
>>>
>>> @Brian, do you want to take this on? If not, I should be able to knock
>>> it out over the weekend.
>>>
>>> Wayne
>>>
>>> --
>>> You received this bug notification because you are subscribed to the bug
>>> report.
>>> https://bugs.launchpad.net/bugs/1496049
>>>
>>> Title:
>>> 4.0.0 RC1 cannot find help
>>>
>>> Status in KiCad:
>>> New
>>> Status in KiCad 4.0 series:
>>> New
>>>
>>> Bug description:
>>> On Windows the 4.0.0 RC1 install cannot find it's own help.
>>>
>>> The help is at C:\Program
>>> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>>>
>>> The searched paths are like this:
>>>
>>> Path
>>> C:\msys64\mingw64
>>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>>> C:\Program Files\KiCad\kicad.html
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\kicad.html
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>>> C:\Program Files\KiCad\kicad.pdf
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\kicad.pdf
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
>>> C:\Program Files\KiCad\kicad.html
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\kicad.html
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
>>> C:\Program Files\KiCad\kicad.pdf
>>> C:\Program Files\KiCad
>>> C:\Program Files\KiCad\kicad.pdf
>>> C:\...

Read more...

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (10.5 KiB)

Correct. Externally defined environment variable take precedence over
the ones defined in the path configuration dialog. These environment
variables will be high lighted in the dialog to indicate that they are
externally defined. You can edit the path of externally defined
environment variable but they will not change the actual environment
variable that the current process uses. You wound have to close kicad,
remove the externally defined environment variable, then open kicad and
the value you entered in the dialog would take effect.

On 9/17/2015 3:12 PM, Nick Østergaard wrote:
> Yes, and can't they be changed by a system env var?
>
> 2015-09-17 21:01 GMT+02:00 Wayne Stambaugh <email address hidden>:
>> Nick,
>>
>> Not necessarily. The fp-lib-table dialog shows the paths that will be
>> substituted in the fp-lib-table plus a few others like KISYS3DMOD of
>> which I am not sure why.
>>
>> Wayne
>>
>> On 9/17/2015 1:41 PM, Nick Østergaard wrote:
>>> Hi Wayne
>>>
>>> I am still a bit confused here. Are the variables seen in the
>>> footprint library table bottom and all the ones in the configure paths
>>> dialog not supposed to be overridden by a system environment variable?
>>> If so, it does not seem to work.
>>>
>>> 2015-09-17 14:20 GMT+02:00 Wayne Stambaugh <email address hidden>:
>>>> On 9/17/2015 2:17 AM, jean-pierre charras wrote:
>>>>> I am thinking using an environment variable "like the other predefined environment variables" (I am guessing like KISYS3DMOD for instance, which can be set in Configuration Path dialog) is the best way.
>>>>
>>>> This is exactly what I was thinking. Using and environment variable
>>>> also gives the user/developer the flexibility to use any path.
>>>>
>>>>> Using DEFAULT_INSTALL_PATH to find the help files is not good
>>>> (DEFAULT_INSTALL_PATH is not always the actual install path).
>>>>
>>>> This was dependent on the developer setting DEFAULT_INSTALL_PATH
>>>> correctly. It may have been wishful thinking on my part. It also
>>>> doesn't work on systems with installers that allow installation in a
>>>> user selected path that doesn't match the default path.
>>>>
>>>>> This is the best way because like KISYS3DMOD the doc path:
>>>>> - Can be set to the actual path ( not known at build time ) by the user or the installer.
>>>>> - Is clearly known in the dialog
>>>>>
>>>>
>>>> @Brian, do you want to take this on? If not, I should be able to knock
>>>> it out over the weekend.
>>>>
>>>> Wayne
>>>>
>>>> --
>>>> You received this bug notification because you are subscribed to the bug
>>>> report.
>>>> https://bugs.launchpad.net/bugs/1496049
>>>>
>>>> Title:
>>>> 4.0.0 RC1 cannot find help
>>>>
>>>> Status in KiCad:
>>>> New
>>>> Status in KiCad 4.0 series:
>>>> New
>>>>
>>>> Bug description:
>>>> On Windows the 4.0.0 RC1 install cannot find it's own help.
>>>>
>>>> The help is at C:\Program
>>>> Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>>>>
>>>> The searched paths are like this:
>>>>
>>>> Path
>>>> C:\msys64\mingw64
>>>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>>>> C:\Program Files\KiCad\kicad.html
>>>> C:\Program Files\KiCad
>>>> C:\Prog...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :
Download full text (16.2 KiB)

Yeah sure I can pick this work up, but first I want to define it. The
rabbit hole gets deeper for me...

It looks like it's wanted to introduce a KIHELP env var and set it in
the configuration path dialog as per the other env var settings. No
problem.

I just checked something which works out okay, and that's variable
substitution in the path values.

A Windows installer should set the KICAD environment variable to the
installation path (Generally "C:\Program Files\KiCad").

The default values of the other variables can then be
"${KICAD}\share\kicad\template" for the KICAD_PTEMPLATES setting, etc.
That works here, ${KICAD} is correctly expanded to "C:\Program
Files\KiCad" and thus the whole value becomes correct. Perhaps we
should add the KICAD value to the path configuration dialog too?

So for Windows at least the default KIHELP path would be
"${KICAD}\share\doc\kicad\help" and then we'll add the locale
information on as normal. Does that sound reasonable? I suggest on
Windows we alter all of the default paths like KISYS3DMOD and KISYSMOD
like this too so they all start with ${KICAD}

All paths are currently knackered under the Windows install. Project
templates cannot be found, that path is broken too.

I suggest from here, some chat on the Dev mailing list about paths and
what we can do to sort them out in KiCad and the packaging and then
fix all the problems for the next RC. KiCad is really quite crippled
out-of-the-box on Windows at the moment.

Thanks, and sorry the discussion about the bug is so long, I know
we're all short on time.

Best Regards,

Brian.

On 17 September 2015 at 20:31, Wayne Stambaugh
<email address hidden> wrote:
> Correct. Externally defined environment variable take precedence over
> the ones defined in the path configuration dialog. These environment
> variables will be high lighted in the dialog to indicate that they are
> externally defined. You can edit the path of externally defined
> environment variable but they will not change the actual environment
> variable that the current process uses. You wound have to close kicad,
> remove the externally defined environment variable, then open kicad and
> the value you entered in the dialog would take effect.
>
> On 9/17/2015 3:12 PM, Nick Østergaard wrote:
>> Yes, and can't they be changed by a system env var?
>>
>> 2015-09-17 21:01 GMT+02:00 Wayne Stambaugh <email address hidden>:
>>> Nick,
>>>
>>> Not necessarily. The fp-lib-table dialog shows the paths that will be
>>> substituted in the fp-lib-table plus a few others like KISYS3DMOD of
>>> which I am not sure why.
>>>
>>> Wayne
>>>
>>> On 9/17/2015 1:41 PM, Nick Østergaard wrote:
>>>> Hi Wayne
>>>>
>>>> I am still a bit confused here. Are the variables seen in the
>>>> footprint library table bottom and all the ones in the configure paths
>>>> dialog not supposed to be overridden by a system environment variable?
>>>> If so, it does not seem to work.
>>>>
>>>> 2015-09-17 14:20 GMT+02:00 Wayne Stambaugh <email address hidden>:
>>>>> On 9/17/2015 2:17 AM, jean-pierre charras wrote:
>>>>>> I am thinking using an environment variable "like the other predefined environment variables" (I am gu...

Revision history for this message
Nick Østergaard (nickoe) wrote :
Download full text (20.8 KiB)

I think it makes sense to derive the other vars after a KICAD var as
Wayned suggested earlier.

But Wayne, have you tried to override the KISYSMOD with a systme env
var recently? I can't make it work on linux nor windows. I think it is
broken. The only variable I was able to change, that I tried, was the KIPRJMOD.

2015-09-17 22:44 GMT+02:00 Brian Sidebotham <email address hidden>:
> Yeah sure I can pick this work up, but first I want to define it. The
> rabbit hole gets deeper for me...
>
> It looks like it's wanted to introduce a KIHELP env var and set it in
> the configuration path dialog as per the other env var settings. No
> problem.
>
> I just checked something which works out okay, and that's variable
> substitution in the path values.
>
> A Windows installer should set the KICAD environment variable to the
> installation path (Generally "C:\Program Files\KiCad").
>
> The default values of the other variables can then be
> "${KICAD}\share\kicad\template" for the KICAD_PTEMPLATES setting, etc.
> That works here, ${KICAD} is correctly expanded to "C:\Program
> Files\KiCad" and thus the whole value becomes correct. Perhaps we
> should add the KICAD value to the path configuration dialog too?
>
> So for Windows at least the default KIHELP path would be
> "${KICAD}\share\doc\kicad\help" and then we'll add the locale
> information on as normal. Does that sound reasonable? I suggest on
> Windows we alter all of the default paths like KISYS3DMOD and KISYSMOD
> like this too so they all start with ${KICAD}
>
> All paths are currently knackered under the Windows install. Project
> templates cannot be found, that path is broken too.
>
> I suggest from here, some chat on the Dev mailing list about paths and
> what we can do to sort them out in KiCad and the packaging and then
> fix all the problems for the next RC. KiCad is really quite crippled
> out-of-the-box on Windows at the moment.
>
> Thanks, and sorry the discussion about the bug is so long, I know
> we're all short on time.
>
> Best Regards,
>
> Brian.
>
>
> On 17 September 2015 at 20:31, Wayne Stambaugh
> <email address hidden> wrote:
>> Correct. Externally defined environment variable take precedence over
>> the ones defined in the path configuration dialog. These environment
>> variables will be high lighted in the dialog to indicate that they are
>> externally defined. You can edit the path of externally defined
>> environment variable but they will not change the actual environment
>> variable that the current process uses. You wound have to close kicad,
>> remove the externally defined environment variable, then open kicad and
>> the value you entered in the dialog would take effect.
>>
>> On 9/17/2015 3:12 PM, Nick Østergaard wrote:
>>> Yes, and can't they be changed by a system env var?
>>>
>>> 2015-09-17 21:01 GMT+02:00 Wayne Stambaugh <email address hidden>:
>>>> Nick,
>>>>
>>>> Not necessarily. The fp-lib-table dialog shows the paths that will be
>>>> substituted in the fp-lib-table plus a few others like KISYS3DMOD of
>>>> which I am not sure why.
>>>>
>>>> Wayne
>>>>
>>>> On 9/17/2015 1:41 PM, Nick Østergaard wrote:
>>>>> Hi Wayne
>>>>>
>>>>> I am stil...

Revision history for this message
Brian Sidebotham (brian-sidebotham) wrote :

On 17 September 2015 at 22:43, Nick Østergaard
<email address hidden> wrote:
> I think it makes sense to derive the other vars after a KICAD var as
> Wayned suggested earlier.

Sorry Nick, Could you quote that suggestion for me as I can't see anything.

I'm sure what I just described is what we'll all want to do. All the
installer need do is set the KICAD var (The KICAD env var can already
be used as previously mentioned).

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :
Download full text (17.5 KiB)

On 9/17/2015 4:44 PM, Brian Sidebotham wrote:
> Yeah sure I can pick this work up, but first I want to define it. The
> rabbit hole gets deeper for me...
>
> It looks like it's wanted to introduce a KIHELP env var and set it in
> the configuration path dialog as per the other env var settings. No
> problem.

Please use KIHELPDIR. The default can be defined in pgm_base.cpp along
with the other default env vars. I would use the mess in the beginning
of SearchHelpFileFullPath() to determine the platform specific default
help path. After that, the config value should always be used. This
should be a cut an paste effort. Maybe a separate GetDefaultHelpPath()
would be useful.

>
> I just checked something which works out okay, and that's variable
> substitution in the path values.
>
> A Windows installer should set the KICAD environment variable to the
> installation path (Generally "C:\Program Files\KiCad").
>
> The default values of the other variables can then be
> "${KICAD}\share\kicad\template" for the KICAD_PTEMPLATES setting, etc.
> That works here, ${KICAD} is correctly expanded to "C:\Program
> Files\KiCad" and thus the whole value becomes correct. Perhaps we
> should add the KICAD value to the path configuration dialog too?
>
> So for Windows at least the default KIHELP path would be
> "${KICAD}\share\doc\kicad\help" and then we'll add the locale
> information on as normal. Does that sound reasonable? I suggest on
> Windows we alter all of the default paths like KISYS3DMOD and KISYSMOD
> like this too so they all start with ${KICAD}

Make sense for windows, linux also uses
${CMAKE_INSTALL_PATH}/share/doc/kicad/help which should work without
modification. The OSX path stuff is in SearchHelpFileFullPath() as
well. Use the locale look up code in SearchHelpFileFullPath(). I would
just pass the help path to SearchHelpFileFullPath() and remove all of
the search stack gyrations. That code truly deserves to die.

>
> All paths are currently knackered under the Windows install. Project
> templates cannot be found, that path is broken too.
>
> I suggest from here, some chat on the Dev mailing list about paths and
> what we can do to sort them out in KiCad and the packaging and then
> fix all the problems for the next RC. KiCad is really quite crippled
> out-of-the-box on Windows at the moment.
>
> Thanks, and sorry the discussion about the bug is so long, I know
> we're all short on time.
>
> Best Regards,
>
> Brian.
>
>
> On 17 September 2015 at 20:31, Wayne Stambaugh
> <email address hidden> wrote:
>> Correct. Externally defined environment variable take precedence over
>> the ones defined in the path configuration dialog. These environment
>> variables will be high lighted in the dialog to indicate that they are
>> externally defined. You can edit the path of externally defined
>> environment variable but they will not change the actual environment
>> variable that the current process uses. You wound have to close kicad,
>> remove the externally defined environment variable, then open kicad and
>> the value you entered in the dialog would take effect.
>>
>> On 9/17/2015 3:12 PM, Nick Østergaard wrote:
>>> Yes, and ...

Revision history for this message
Nick Østergaard (nickoe) wrote :

I have committed a fix for the kicad windows builder. It is already available in the debug build found on the download page. In a hand full of hours it will be available in the latest nightlies.

Changed in kicad:
status: New → Fix Committed
Wayne Stambaugh (stambaughw)
Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.