Module scope conflicts

Archives Forums/BlitzMax Bug Reports/Module scope conflicts

kfprimm

(Posted 2010) [#1]

To reproduce the first bug, create a module called foo.math with the following source:

Strict

Module Foo.Math

Import BRL.Math

Function Add(num1,num2)
	Return num1+num2
End Function

When building, it will error out with the following:

C:/BlitzMax/mod/foo.mod/math.mod/.bmx/math.bmx.debug.win32.x86.s [10]:
___bb_math_math:
error: symbol already defined.

For the second bug, use the following source:
foo.mod/math.mod/math.bmx

Strict

Module Foo.Math

Function Add(num1,num2)
	Return num1+num2
End Function

foo2.mod/math.mod/math.bmx

Strict

Module Foo2.Math

Function Subtract(num1,num2)
	Return num1+num2
End Function

test.bmx


Strict

Import Foo.Math
Import Foo2.Math

Add(2,1)
Subtract(2,1)

These modules will actually build.

After compiling test.bmx, you should get the following error:

C:/BlitzMax/mod/foo.mod/math.mod/math.debug.win32.x86.a(math.bmx.debug.win32.x86.o): multiple definition of `__bb_math_math'
C:/BlitzMax/mod/foo2.mod/math.mod/math.debug.win32.x86.a(math.bmx.debug.win32.x86.o): first defined here
Build Error: Failed to link C:/Documents and Settings/Owner/Desktop/test.debug.exe

I've tested both under 1.41 on Windows and Linux but I have noticed the behavior in previous versions.

plash

(Posted 2010) [#2]

This is due to the way modules are initialized. An entrypoint is created for each module, and it uses the format "__bb_<modname>_<modname>". It could be that the intended form was "__bb_<scope>_<modname>", and it may have been overlooked in development.

kfprimm

(Posted 2010) [#3]

That's what I was thinking. Normally, I would have figured out a fix but unfortunately that's not possible...

Htbaa

(Posted 2010) [#4]

If the entrypoint is indeed badly configured perhaps this should be changed for the next BlitzMax release. I suppose this will conflict with pre-compiled 3rd party modules but it's worth the pain as it'll give a lot more flexibility.

Brucey

(Posted 2010) [#5]

If the entrypoint is indeed badly configured perhaps this should be changed for the next BlitzMax release

Hah... this is a "feature" of BlitzMax.

This is how it is.

One needs to live with it, and work around it.

Htbaa

(Posted 2010) [#6]

I knew of the current limitation. But if it can be resolved then why not? Can it be changed. And how is this actually a feature?

Brucey

(Posted 2010) [#7]

It's a feature insofar as Mark said it would never be changed.
(there's probably even a post circa 2007 which embellishes on the subject a bit more)

kfprimm

(Posted 2011) [#8]

I'd like to resurrect this report as I've encountered yet another issue that can by no means be intentional.

I've noticed that if you have two modules of different scopes (but the same name) and import both into your source, only the code in latter module (and subsequently all modules it imports) gets executed.

As an example, using my rendering engine,
https://github.com/kfprimm/maxb3d


Strict

Import MaxB3D.Drivers
Import MaxGUI.Drivers

Global ax#, ay#,tim#

Local window:TGadget = CreateWindow("MaxB3D in a canvas", 10, 10, 512, 512, Null,WINDOW_TITLEBAR|WINDOW_RESIZABLE )

Local canvas:TGadget = CreateCanvas(0,0,ClientWidth(window),ClientHeight(window),window,0)
SetGadgetLayout canvas,1,1,1,1

Local camera:TCamera=CreateCamera()
SetEntityColor camera,0,127,255

Local cube:TMesh=CreateCube()

CreateTimer( 60 )

While True
	WaitEvent()
	Select EventID()
	Case EVENT_WINDOWCLOSE
		End
	Case EVENT_TIMERTICK
		RedrawGadget canvas	
	Case EVENT_GADGETPAINT
		SetGraphics CanvasGraphics( canvas )
		SetCameraViewport camera,0,0,ClientWidth(canvas),ClientHeight(canvas)
		
		SetEntityPosition camera,0,0,-5'-50+20*Cos(MilliSecs()/10.0)		
		SetEntityRotation cube,ax,ay,0
		ax:+1
		ay:+5
		
		RenderWorld
		Flip	              
	End Select
Wend

Swap the two imports and you'll see that CreateWindow fails in one order, and CreateCamera fails in the other.