kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>