Well I can't because the two machines are thousands of miles apart and the
one at home is not switched on when I am not there and vice versa.

I am certain the files are the same though and everything worked fine until
I moved some of my code to separate files and used them to avoid main being
massive. That works fine in my summer residence but not in my winter
residence.

This is the only place I define default implementations (blank panels of a
box) and then override them with customised panels with parts on them. It
works if the overrides are in the file that calls them but not if they are
in used files.

Should I expect used files to be searched in reverse order of them being
used, or is it non-deterministic?

On Thu, 16 Jan 2020 at 12:03, MichaelAtOz oz.at.michael@gmail.com wrote:

They are not the same in absolute terms but they are they should be
equivalent. I.e. the folder structure of the project is identical but is
path is different. My OPENSCADPATH variable points to the same library but
it may have a different path. It is the same library though according to
git.

Everything else works the same on both machines. I can run all my library
tests and get the same results give or take a few pixels. It is just this
lookup issue when there are two used files than define the same module. On
my desktop in the UK the last definition wins. Here in the sun the first
definitions wins.

On Thu, 16 Jan 2020 at 23:23, Parkinbot rudolf@digitaldocument.de wrote:

If the absolute paths of the files changes the search order then that might
explain the difference but surely that should not affect the semantics of
the source code.

On Thu, 16 Jan 2020 at 23:31, nop head nop.head@gmail.com wrote:

nophead wrote

Are both of those 'use' == 'use<file>'?

//main.scad
use<file1.scad> // defines module m1(){echo("file1")}
use<file2.scad> // also define module m1(){echo("file2")}
//or perhaps also file1.scad but in another directory??
m1();

You get ECHO: "file1" on one system and "file2" on the other??

Wiki says Help/Library-info shows the libraries & "The locations will be
searched in the order they appear in this list"

Admin - email* me if you need anything,  or if I've done something stupid...

• click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

That works as expected on my laptop, that I have the problem with. I can't
test anything on my desktop until the spring.

My code is actually more complex than that. I actually have a box.scad that
defines all its panels as blanks. I use that in front.scad, sides.scad,
top.scad, etc. Each one of those redefines one panel. I then use all of
those in main.scad after using box.scad, expecting all the blank panels to
be overridden.

I found I had accidentally used box.scad after the other files in main via
an include. Moving that to before fixes most of the panels, except the
front, which only works if it is included after the sides, but I don't
understand why. There is nothing special about sides.scad other than it
defines two panels instead of one. It has no relationship to front.scad.

They other mystery is why it worked on my desktop with the use of box.scad
after all the others. It definitely did because I checked it again when I
was home for a few weeks at Christmas.

I have it working now with a new order of uses, so all that remains is to
see if it works on my desktop. There is definitely some strange going on
but it is very subtle.

On Thu, 16 Jan 2020 at 23:54, MichaelAtOz oz.at.michael@gmail.com wrote:

I use "use" to mean use<> and "include" to mean include<>.

Unfortunately my code is far too big to post as it is a 3D printer made
from hundreds of files and so far I haven't managed to distil a small
example .

I don't fully understand the paragraph you quoted but it sounds like it
might be relevant but still doesn't explain why two PCs give different
results with the same code.

On Fri, 17 Jan 2020 at 11:20, MichaelAtOz oz.at.michael@gmail.com wrote: