Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


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

nophead opened this Issue · 9 comments

4 participants

Chris Felipe Corrêa da Silva Sanches Marius Kintel Steve Kelly

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.

Felipe Corrêa da Silva Sanches

I am also affected by this bug.

Marius Kintel

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.

Marius Kintel

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.

Marius Kintel kintel referenced this issue

Issue217 #326

Marius Kintel

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

Marius Kintel

dxfdim() issue fixed in #338

Marius Kintel

Fixed by #326

Marius Kintel kintel closed this
Marius Kintel kintel reopened this
Marius Kintel

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() {
Steve Kelly

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.

Marius Kintel

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.

Marius Kintel kintel closed this issue from a commit
Marius 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
Marius Kintel kintel closed this in 0e93836
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.