Import paths not relative to the file with the import. #217

nophead opened this Issue Nov 6, 2012 · 14 comments

5 participants


They seem to be relative to the top level file so one cannot use a module with a relative import from more than one directory.


I am also affected by this bug.

openscad member

Comment from Felipe:

I'm developing an openscad library of pinball parts.

The library is saved in a directory and the scad script that uses the
library is typically in a different directory.
One of the modules in the library imports curves from a DXF file. When
I load the module directly from the library it renders ok. But when I
use the library (with the use <../pinball/something.scad>; statement )
from a scad script in a different path, the DXF fails to load.

The path for loading a file for the import statement should be the
same path of the module that uses it. I consider it to be a bug
because it makes it almost impossible to implement a proper library
that uses DXF files in its modules.

@kintel kintel added a commit that referenced this issue Apr 5, 2013
@kintel kintel I think this should fix issue #217 1b8b7aa
openscad member

I finally managed to dig through the mess it was to figure this out.
After a 900 line patch which I scrapped, it turned out to be more elegant to do it in a slightly less intrusive way..

Anyway, it lives in the issue217 branch for now, so if anyone wants to test it, it would be cool.

@kintel kintel referenced this issue Apr 5, 2013

Issue217 #326

openscad member

Remaining issue: We still cannot do relative lookups of files which are accessed with a dxfdim() call.

openscad member

dxfdim() issue fixed in #338

openscad member

Fixed by #326

@kintel kintel closed this Apr 27, 2013
@kintel kintel reopened this May 7, 2013
openscad member

Found a regression, see example below.

In OpenSCAD <= 2013.01, we required somestl.stl to be located relative to main.scad. Currently we require it to be relative to lib.scad, and we thus fail on existing files expecting the old behavior.

Suggested fix:

  • Search for file by first checking locally, then relative to the main file.
  • If the file is found in the old location, issue a deprecation warning.





module libmodule() {

Is this currently affecting master? The latest as of now is broken for my current project. Everything works in 2013.01. I will try digging into the problem a bit.

openscad member

Yes, the current master breaks some old files. The new functionality is the good one though, so it makes sense to rewrite. but I'll look into ensuring backwards compatibility.

@kintel kintel added a commit that closed this issue May 9, 2013
@kintel kintel Search for included files first in the same location as the including…
… module, then in the document root as a compatibility fallback. Fixes #217
@kintel kintel closed this in 0e93836 May 9, 2013

Has this issue reappeared?

I'm having what seems to be exactly this issue with version 2015.03-1: I import a DXF relative to a file in a library and cannot use that module in anything other than the directory that contains the module.

openscad member

@DanNixon It should work - could you provide an example?


I have the directory structure:

├── DXF
│   └── HDDs
│       ├── HDD25_Bottom.dxf
│       ├── HDD25_Side.dxf
│       ├── HDD35_Bottom.dxf
│       └── HDD35_Side.dxf
└── SCAD
    ├── HDD25.scad
    └── HDD35.scad

Where the SCAD folder is added as a library in .local/share/OpenSCAD/libraries.

HDD25.scad and HDD35.scad contain modules that import the shown DXF's using a relative path, when I have a file (test.scad) in the SCAD directory as follows I get what I expect:

include <SCAD/HDD25.scad>;

If I place test.scad anywhere else I get:

WARNING: Can't open DXF file '/home/dan/../DXF/HDDs/HDD25_Bottom.dxf'. 
WARNING: Can't open DXF file '/home/dan/../DXF/HDDs/HDD25_Side.dxf'. 

This is one of the modules causing the issue.

openscad member

You have to use use <SCAD/HDD25.scad> rather than include.... When using include, you use the context of where the included module lives. That's a separate issue and is not likely to be improved until we redesign the module inclusion mechanism.


@kintel Ah thanks, that is working for me now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment