On Thu, 21 Jan 2010 18:59:36 +0100
Dimitris Lampridis <[email protected]> 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
