← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] Look in PATH for binaries

 

On 7/22/2012 5:55 AM, Denis Kuzmenko wrote:
Wayne,

Do you mean that you run the kicad application from the build directory?  If
so, that is your problem.  Each KiCad child application is built in it's own
directory which means you would have to add each application build directory
to your PATH variable.  Obviously that would be rather cumbersome.  When I'm
testing new builds I generally run the application (eeschema, pcbnew)
directly rather than launching them through kicad. If I need to debug the
interaction between kicad and it's child applications then I install
everything in a separate temporary folder by setting
-DCMAKE_INSTALL_PREFIX=~/some_test_path when I run cmake to create my build
environment.  Then all I have to do is export PATH=~/some_test_path:$PATH
from the command line and kicad can find all of it's child apps.

I run kicad from build directory. Yes it's cumbersome, but it is a
most natural and obvious way to solve that problem.
Can't understand why do we have couple *hardcoded* paths but don't
have PATH env. variable support?

The hard coded paths make sense when KiCad is installed on a system which is how KiCad is normally used not when it resides in a dozen different build paths. I would be more open to a last resort option to just attempt to run a child application from kicad and hope it that can be found by the system. This would be a better alternative than adding every path in the $PATH environment variable to the kicad search list.

My patch just adds another way to do things and I believe that it
would not break other functionality. So why wouldn't accept it?

It's not a matter of whether or not it breaks anything. Developer preferences really don't belong in the source because every developer tends to do things their own way (which is a good thing). Adding developer specific code would not be a good thing and would likely spiral out of control. Developers generally prefer their own build environment configuration. Adding one developers preferences into kicad is likely to break another developers preferences.


PS: we should add "-DCMAKE_INSTALL_PREFIX=~/some_test_path" to
HOW_TO_CONTRIBUTE.txt.

CMAKE_INSTALL_PREFIX is a standard CMake variable and is already well documented in the CMake documentation. I'm not sure it makes sense to document it again in KiCad. Maybe a link to the CMake documentation so developers can learn to use CMake effectively would be a good thing.

Regards,

Wayne


Best Regards, Denys Kuzmenko.


2012/7/22 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>:
On 7/21/2012 4:26 PM, Denis Kuzmenko wrote:

Hi Wayne.

Here's my problem:
when I launch freshly built kicad and try to open schematic it says
"Command <eeschema> not found".
With my patch I can avoid that:
export PATH=$PATH:`pwd`/eeschema/
kicad/kicad


Do you mean that you run the kicad application from the build directory?  If
so, that is your problem.  Each KiCad child application is built in it's own
directory which means you would have to add each application build directory
to your PATH variable.  Obviously that would be rather cumbersome.  When I'm
testing new builds I generally run the application (eeschema, pcbnew)
directly rather than launching them through kicad. If I need to debug the
interaction between kicad and it's child applications then I install
everything in a separate temporary folder by setting
-DCMAKE_INSTALL_PREFIX=~/some_test_path when I run cmake to create my build
environment.  Then all I have to do is export PATH=~/some_test_path:$PATH
from the command line and kicad can find all of it's child apps.



But I failed how to manage that with ldconfig command. Can you give me
some hints? Should I add `pwd`/eeschema/ to the library cache?


This is correct, ldconfig is for managing shared objects not executables.
The PATH environment variable is used to tell the system where to find
executables.  I cannot see how using $PATH within kicad to find executables
buys you anything.


Wayne




Best Regards, Denys Kuzmenko.


2012/7/21 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>:

There already is a better way.  It's called ldconfig.  This is how you
manage library paths in Linux.  It allows you to add custom paths to your
hearts content.  You can even add temporary paths in a console for
debugging
custom libraries.  I see no reason add something to KiCad that is handled
at
the system level.  I would not support any patch that would disregard the
system level library management.  Windows is another story since it does
not
have a library manager other than the PATH environment variable in which
case you would just use the PATH environment variable.

Wayne


On 7/21/2012 12:41 PM, Denis Kuzmenko wrote:


Hi Arius,

I've tried to find some better way but failed.
Any suggestions on how to do it better?
Anyways this code will not break windows but will give additional
feature to Linux distribution.


Best Regards, Denys Kuzmenko.


2012/7/21 arius <cpp.development@xxxxxxxxxxxxxx>:



Hm, this seems not to be a Windows compatible solution, because the
path
separator there is typically ";".

________________________________
Von: Denis Kuzmenko <dart@xxxxxxxxxxxxxx>
An: kicad-developers@xxxxxxxxxxxxxxxxxxx
Gesendet: 1:55 Dienstag, 17.Juli 2012
Betreff: [Kicad-developers] [PATCH] Look in PATH for binaries

Hi,

This patch makes software to look also in PATH environment variable
directories for binaries to launch.



Best Regards, Denys Kuzmenko.

=== modified file 'common/gestfich.cpp'
--- common/gestfich.cpp 2012-01-26 19:48:45 +0000
+++ common/gestfich.cpp 2012-07-16 23:50:22 +0000
@@ -40,6 +40,8 @@
#include <wx/mimetype.h>
#include <wx/filename.h>
#include <wx/dir.h>
+#include <wx/utils.h>
+#include <wx/tokenzr.h>

/* List of default paths used to locate help files and KiCad library
files.
    *
@@ -409,6 +411,19 @@
               return FullFileName;
       }

+    /* Look in PATH environment variable */
+    wxString path;
+    wxGetEnv(wxT("PATH"), &path);
+
+    wxStringTokenizer tkz(path, wxT(":"));
+    while(tkz.HasMoreTokens())
+    {
+       FullFileName = tkz.GetNextToken() + shortname;
+
+       if( wxFileExists( FullFileName ) )
+                       return FullFileName;
+    }
+
       return shortname;
}

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




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



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







Follow ups

References