kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

Hi Wayne,

 The new resolver will expand variable names; any path specified in a kicad
pcb file or footprint file will be interpreted in exactly the same way as
with the older system. The only difference with the new system is that
there is no need for environment variables (but they will be interpreted if
present). The idea was that users could use the GUI to specify the search
paths and give those paths names (aliases) which are analogous to the
environment variables, except that they aren't environment variables. I
think this is a Good Thing because fiddling with environment variables on
MSWin and OSX is a nuisance. I imagine some Linux users might find env vars
a nuisance as well, especially if they launch kicad from a desktop UI.

 I'll check out the issue with the software rejecting ${ENV_VAR} in the
file name editor.

 If we agree that a "../" style of relative path can only be interpreted as
relative to the current project directory then I think that style of
relative path may in fact be better in many ways than an absolute path
(until a user moves the project directory).  Some users prefer that style
of relative path for their particular workflow so I can implement that if
there are no objections.

 The other differences between the new resolver and the old system:
a. a partial path like "path/to/my/file.wrl" will be interpreted as a path
within the current working directory (new behavior) and if it doesn't exist
there then it will be interpreted as a path within the ${KISYS3DMOD}
directory (old behavior).
b. due to the new behavior in (a), there is no need for "${KIPRJMOD}" - a
partial path will always be checked against the current project directory.

So a summary of the new resolver:
a. env vars are not needed, but still supported (except for the issue
mentioned in the filename editor)
b. multiple model root paths are supported via aliases rather than env var;
an aliased name appears to the user as
"alias_name:my/partial/path/to/mymodel.wrl"; within the PCB file the alias
itself appears as ":alias_name:my/partial/path/to/mymodel.wrl".

- Cirilo

On Tue, Apr 12, 2016 at 10:54 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> Hey Cirilo,
>
> Does the new 3D file path resolve no longer support environment variable
> expansion?  If it doesn't, it should.  We've have had so many issues
> with relative paths in the past that I'm reluctant to allow them.
> That's the primary reason we support environment variable expansion in
> the fp-lib-table and the old 3D file path code because it's infinitely
> more portable than relative and absolute paths.  I know this is not the
> easiest issue to resolve but the best solution I've seen is how
> fp-lib-table handles them.  If someone has any better ideas, I'm open to
> suggestion.
>
> Cheers,
>
> Wayne
>
> On 4/12/2016 2:18 AM, Cirilo Bernardo wrote:
> > Hi folks,
> >
> >  The current behavior of the 3D filename resolver is to use
> > an absolute path in instances where a specified path is
> > not a descendant of a path within the aliased paths list
> > (that is, the filename cannot be shortened using an existing
> > alias). This decision was originally made to avoid ambiguous
> > relative paths such as "../../some/path" (what is it
> > relative to?).  The obvious down side of course is that
> > absolute paths are not portable and this scheme would
> > be a nuisance to people who want to share their work
> > somehow.  Since a number of people seem to be reliant
> > on using the "../" form of relative path to share their work,
> > I'd like to know people's opinions on using such relative
> > paths. If such relative paths are preferred to absolute
> > paths then I can make changes to the code such that
> > the resolver will assign a path relative to the Current
> > Project Directory rather than an absolute path in cases
> > where the file path cannot be shortened via the use of
> > an alias.
> >
> >
> > - 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
> >
>
> _______________________________________________
> 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
>