kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2015-09-14 5:31 GMT+02:00 Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>:
> Hi folks,

Hi, I will just try to reply with some observations that I have done as a user.

>  I was just looking into how KiCad currently handles partial paths for
> files and I have found:
>
> (a) 3D model paths are now resolved exclusively via the KISYS3DMOD
> environment variable

This is not exclusively, maybe from a GUI standpoint, but... I have
used ${KIPRJMOD} as the root of the searchpath in the 3D model path. I
did this for portability. It looks like this in the kicad_pcb file:
(model ${KIPRJMOD}/lib/px0707-s-06-wings3d.wrl

> (b) kiface_i.cpp contains what appears to be some dead code:
> (lines 64 - 76):
>
>         // Add PCB library file path to search path list.
>         if( aId == KIWAY::FACE_PCB || aId == KIWAY::FACE_CVPCB )
>         {
>             fn.AppendDir( wxT( "modules" ) );
>             aDst->AddPaths( fn.GetPath() );
>
>             // Add 3D module library file path to search path list.
>             fn.AppendDir( wxT( "packages3d" ) );
>             aDst->AddPaths( fn.GetPath() );
>
>             fn.RemoveLastDir();
>             fn.RemoveLastDir();     // "../../" up twice, remove
> modules/packages3d
>         }
>
> While I haven't checked if "modules" is used (I presume it is since
> schematic
> symbols are there), I don't believe the "packages3d" directory is ever
> searched
> via the SEARCH_STACK object. I suggest we remove the lines 70..74:
>             // Add 3D module library file path to search path list.
>             fn.AppendDir( wxT( "packages3d" ) );
>             aDst->AddPaths( fn.GetPath() );
>
>             fn.RemoveLastDir();
>
> My reasons are (1) anyone who's already set up to use 3D models is
> no doubt using KISYS3DMOD and (2) the 3D code in my refactoring
> branch will have its own configuration file containing path roots for
> 3D models and will not use SEARCH_STACK anyway. (Then again
> I can always make a small change to use SEARCH_STACK.)

So (1) does not look like a true statement in my eyes, but maybe I
misunderstood your scope.

> Another suggestion for SEARCH_STACK: there are obviously a
> few hard-coded assumptions about paths and paths are added
> without checking that (a) they exist and (b) they are directories.
> If we eliminate candidate paths which do not exist or are not
> directories then we may save some time otherwise wasted
> searching non-existent paths; this will also avoid the error which
> I frequently get complaining about items not being available
> in non-existent paths.

Just a note. If you are trying to override the KISYS3DMOD variable,
from your environment, it will only override it if the string is a
valid path. (This is probably on a tangent to this discusison.)