kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

Hi Bernhard,


On Wed, Jan 13, 2016 at 12:25 AM, Bernhard Stegmaier <
stegmaier@xxxxxxxxxxxxx> wrote:

>
>
>
> Hi,
>
> wrt (2):
>
> I don't think converting to a relative path is a good idea (as I
> understood it).
> I work on one project on different machines (desktop vs. laptop) via
> git/subversion/whatever.
> Both do not have to have the same overall file layout.
> If project stores path relative to itself, it won't work if machines don't
> have identical layout.
>
> What is so bad about having references relative to *one single* base path
> configured in the local machine or KiCad instance like the $KISYS3DMOD path
> we have now?
>
>
Having a single reference point is extremely inflexible - how do you handle
user models? If a
package manager installs the files and you add to the directories then your
changes can be
overwritten later. If the directories are read-only then the user can't add
models. Some people
use ${KIPRJMOD} or other environment vars in the model names to work around
the current
limitations. Even if we had a scheme like fp-lib-table different users will
have to create
corresponding nicknames on different installations.

The "../" relative paths will naturally fail since the chances are the
other installation does not
have the same directory structure but there is really no solution to that
other than to have
a function in kicad which creates local copies of all the files it uses and
changes its internal
state to make use of those files. In the case of pcbnew all the footprints
are cached within
the kicad_pcb file itself but this makes no sense at all for 3D models. So
without such an
export-friendly function we have a choice to fail with paths that start
with '../' or else with
'c:\', '/home/someuser' etc.

- Cirilo


> This way only the layout of the 3d-models library itself has to be the
> same on all machines.
> But, I guess this will be true almost any time, because you probably will
> sync it from one repository.
>
>
>
> Regards
> Bernhard
>
> On 2016-01-12 02:05, Cirilo Bernardo wrote:
>
> Hi folks,
>
>  I'm looking for some comments/suggestions on how to deal with 3D model
> filename resolution. My current 3D refactor branch behaves in much the
> same way as the main branch except that I can specify many model
> search paths. Issues with this scheme include:
>
> 1. how do we deal with multiple equivalent filenames
>
> 2. when the file's full path is not a superset of an existing search path
> how do we ensure that the stored path is a valid path on MSWin/Linux/
> OSX?
>
> For (1) I'm thinking we can use a scheme similar to fp-lib-table where we
> specify a 'nickname' for a base path and provide for an optional comment/
> description. The chief issue I see with this scheme is that the kicad_pcb
> file will have to contain the nickname within the model name and earlier
> versions of kicad will not be able to process project files which have the
> nickname in the model name. This may not be such a big problem as the
> user can do a string replacement to transform the names, but if data is
> being shared both ways between 2 different kicad versions then the model
> naming can be a nuisance.
>
> For (2) I was thinking of converting the path to a path relative to the
> project
> directory. So "/home/user/models/a3dmodel.wrl" or "c:\models\a3dmodel.wrl"
> might become something like "../models/a3dmodel.wrl". The relative path
> will not necessarily exist on another computer but at least we don't have
> the complication of a MSWin vs UNIX file path root.
>
> Any comments/suggestions?
>
> - Cirilo
>
> _______________________________________________
> 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
>
>