--- In [email protected], Dimitris Lampridis <d.lampri...@...> wrote:
>
> On Thu, 21 Jan 2010 18:59:36 +0100
> Dimitris Lampridis <d.lampri...@...> wrote:
>
> > Dear all,
> >
> > I've recently completed the design of my first board with Kicad and
> > I'm extremely happy with it. What a great piece of software it is!
> >
> > However, I ran into a small problem:
> >
> > I've put my design under version control (using Git) so that I can
> > access it and update it from multiple computers, whether I'm at work,
> > at home, or travelling.
> >
> > When I "pull" the latest version from Git, I noticed that most of the
> > paths to custom components are absolute. In other words, a custom
> > module for a footprint that I've created is linked with its aboslute
> > path (eg. if my project is stored at "/home/xxx/projects/yyy", then a
> > custom module could
> > be /home/xxx/projects/yyy/custom_modules/kk-ll.mod).
> >
> > Of course, not all of the computers have the same installations and
> > folder structures (or user names for home folders), so this approach
> > fails.
> >
> > Especially under version control, the problem becomes bigger: if I
> > modify the paths to match one system, then commit my changes, the
> > project will stop working on every other computer...
> >
> > To solve this, I manually changed all paths that point to custom
> > components (for library symbols, footprint modules and 3D models) into
> > relative ones (eg. ./custom_modules/kk-ll.mod).
> >
> > This worked for symbols and footprints like a charm, but the 3D viewer
> > refuses to draw the components that are given with relative paths.
> >
> > Anybody knows why this is happening? Any solutions?
> >
>
>
> Well, to answer my own question and provide a permanent solution to
> this (I later discovered that this has been discussed a number of times
> in this group, but with no "real" solution), I decided to have a look at
> the source code of kicad.
>
> To begin with, I'm using Debian, so I pulled the source code of the
> Debian package (version 0.0.20090216-1).
>
> I first studied the way eeschema and pcbnew handle relative paths, and
> I then compared it to way that 3d_viewer does it.
>
> I realized that there is a handy function (MakeFileName) available,
> which handles absolute and relative paths correctly, and which is being
> used by eeschema and pcbnew, but not by 3d_viewer (developers must
> have forgotten to do it).
>
> I then modified the source code of 3d_viewer (in file 3d_read_mesh.cpp)
> to make use of MakeFileName() function (defined in header file
> "gestfich.h", and recompiled the source.
>
> I tested the result on a number of systems and it works great! Now all
> symbols, footprints and 3d models can have relative paths (as well as
> absolute, and of course support for built-in libraries).
>
> I've uploaded a .diff file to the kicad-users group folders. It can be
> found inside folde "DL_files".
>
> Here's a copy of the diff itself, for reference. Its really simple,
> and it should also apply to the SVN tree of kicad as well:
>
> --- original/kicad-0.0.20090216/kicad/3d-viewer/3d_read_mesh.cpp
> 2009-02-04 16:25:03.000000000 +0100 +++
> modified/kicad-0.0.20090216/kicad/3d-viewer/3d_read_mesh.cpp
> 2010-01-22 11:36:10.863021187 +0100 @@ -11,6 +11,7 @@
> #include "fctsys.h"
> #include "common.h"
> +#include "gestfich.h"
> #include "macros.h"
> #include "kicad_string.h"
>
> @@ -32,18 +33,7 @@
> return 1;
> }
>
> - if( wxIsAbsolutePath( m_Shape3DName ) )
> - fullfilename.Empty();
> - else
> - fullfilename = g_RealLibDirBuffer + LIB3D_PATH;
> - fullfilename += m_Shape3DName;
> -#if defined (__WINDOWS__)
> - fullfilename.Replace( UNIX_STRING_DIR_SEP, WIN_STRING_DIR_SEP );
> -#else
> -#if defined (__UNIX__)
> - fullfilename.Replace( WIN_STRING_DIR_SEP, UNIX_STRING_DIR_SEP );
> -#endif
> -#endif
> + fullfilename = MakeFileName ( g_RealLibDirBuffer + LIB3D_PATH,
> m_Shape3DName, wxT(".wrl") );
> file = wxFopen( fullfilename, wxT( "rt" ) );
> if( file == NULL )
>
>
> Can the developers pick it up from here or should I talk to them in the
> kicad-devel group?
>
> Cheers,
> Dimitris
>
Wow, nicely done! I'm not at all that proficient with C++, I couldn't even get
the unmodified 3d_read_mesh to compile without a long list of errors..
Anyway, been using kicad on and off for about a year now, and I really like it.
Except, it does have some drawbacks too, and lack of relative paths is a major
one!
However, I believe I have solved it today :) No guarantees though, I havent
tested this extensively,in fact it is just barely tested on one project, and
only one computer, since I haven't gone through my point 3 in the list below
myself yet... but I assume it works. It also works in 3D viewer.
Feedback is welcome of course.
In short, one must use symbolic links. I'm using linux Ubuntu 9.10 atm. How
this will affect projects loaded into a windows installation of kicad I dont
know however.. I don't remember windows commands, maybe a subst, maybe some
alias(?). I doubt windows shortcuts will work the same as symbolic links.
Now for the slightly longer tutorial; Relative paths in kicad in 3 easy steps :)
1 - Have your custom kicad stuff (libraries you make or download) easily
available.
NOTE: The below is just a suggestion, sort of based on how I have my folder
structure. Yours might vary, change as appropriate. For instance, if you don't
like to mix the custom library folder with your kicad projects folder, put it
in another folder.
I recommend making your own kicad folder inside your home folder, for
kicad-related stuff. That is, your projects and also custom libraries/modules
(footprints), and 3D shapes.
Say your username is gowron, make a "kicad" folder in your home folder:
/home/gowron/kicad
In this folder I also recommend having each project in their own subfolder.
Also inside this folder, make a "libraries" folder to hold all the libraries
and footprints ("modules" in kicad)
/home/gowron/kicad/libraries
And the last one, a subfolder to hold (custom) 3D shapes:
/home/gowron/kicad/libraries/packages3D
Like I said, this is just a suggestion, but I hope it makes it easy to navigate
to these folders from kicad when setting directories for libraries, modules and
3D shapes.
2. Create a symbolic link to the path where you store your custom kicad stuff
(IE the libraries and modules).
Using linux (ubuntu), the $HOME environment variable points to your home
directory, and can be used regardless of your username:
Start a command line (terminal in ubuntu):
ln -s $HOME/kicad/libraries userlibs
Now you have a symbolic link inside your home folder, named "userlibs". It will
look like a folder. But this is not where it should be. Now its time to copy
this link to two locations within kicad's default library folder.
To do so you must be root, or a super user. So be careful with what you do when
you are!
one easy GUI way, is to start nautilus (the file browser) in super user mode.
In terminal, type:
gksu nautilus
Then navigate to your home folder /home/gowron, find the symbolic link named
"userlibs", right-click and copy it.
Now navigate to kicad's packages3D folder,
"/usr/share/kicad/modules/packages3D". Copy the symbolic link here.
Also copy the symbolic link to the "/usr/share/kicad/library" folder.
3. Edit your projects to use the symbolic link you created.
Depending on how many projects and custom libraries you got, this might be a
tedious job.
For EEschema schematics, go to menu preferences - libs and dir:
Just click on the "userlibs" symbolic link, and find your libraries and add
them. Remove the old ones with the old absolute paths.
For PCBnew, almost the same (preferences - libs and dir):
Click the "packages3d" folder, then the "userlibs" symlink. Then find your
modules you used. Remove the old ones with the old absolute paths.
Editing lots of modules with their respective 3D shapes can be tedious, and
also exchange those modules in kicad PCBnew to reflect the changes. But that is
for another little how-to (how to change or update modules in PCBnew).
Once done, you can easily transfer your projects to other installations with
other usernames. For windows systems I don't know.
I would really recommend settling for a standard convention as to what to call
the symbolic link, and also how to have the folder structure under it. That way
it would really facilitate transferring projects between different computers.
