www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - May be a simple dub answer if my question even makes sense?

reply WhatMeWorry <kheaser gmail.com> writes:
I have D opengl/glfw3 program that I wrote which compiles and 
runs fine, but I always felt it was a bit of a Visual Studio 
hack.   So I thought I'd start anew but this time use dub from 
the get go.  So I did dub int...etc.  And put my existing code 
into the app.d file.  But when I try to build the project with 
dub build, I get

dub build --arch=x86_64 --force
Performing "$DFLAGS" build using dmd for x86_64.
derelict-util 2.1.0: building configuration "library"...
derelict-al 1.0.1: building configuration "library"...
derelict-fi 2.0.2: building configuration "library"...
derelict-ft 1.1.2: building configuration "library"...
derelict-gl3 1.0.19: building configuration "library"...
derelict-glfw3 3.1.0: building configuration 
"derelict-glfw3-dynamic"...
01_01_hello_window ~master: building configuration 
"application"...
source\app.d(154,5): Error: undefined identifier 'glViewport'
source\app.d(157,13): Error: undefined identifier 
'glfwWindowShouldClose'
source\app.d(160,9): Error: undefined identifier 'glfwPollEvents'
source\app.d(166,9): Error: undefined identifier 'glClearColor'
source\app.d(167,9): Error: undefined identifier 'glClear'
source\app.d(170,9): Error: undefined identifier 'glfwSwapBuffers'
source\app.d(174,5): Error: undefined identifier 'glfwTerminate'
dmd failed with exit code 1.
myapp exited with code 2

I see that dub has all the .d import files already placed in
C:\Users\Me\AppData\Roaming\dub\packages\derelict-gl3-1.0.19\derelict-gl3\source\derelict\opengl3

and 
C:\Users\Me\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3

which should have all the definitions.  Is their an elegant way 
that I can tell dub to where these definitions? Or do I just have 
to brute force all the -I paths?

I assume there is a slick way of specifying this because what 
happens when say glfw3-3.1.0 gets bumped up to 3.1.1?
Sep 23 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 24/09/2016 2:33 PM, WhatMeWorry wrote:
 I have D opengl/glfw3 program that I wrote which compiles and runs fine,
 but I always felt it was a bit of a Visual Studio hack.   So I thought
 I'd start anew but this time use dub from the get go.  So I did dub
 int...etc.  And put my existing code into the app.d file.  But when I
 try to build the project with dub build, I get

 dub build --arch=x86_64 --force
 Performing "$DFLAGS" build using dmd for x86_64.
 derelict-util 2.1.0: building configuration "library"...
 derelict-al 1.0.1: building configuration "library"...
 derelict-fi 2.0.2: building configuration "library"...
 derelict-ft 1.1.2: building configuration "library"...
 derelict-gl3 1.0.19: building configuration "library"...
 derelict-glfw3 3.1.0: building configuration "derelict-glfw3-dynamic"...
 01_01_hello_window ~master: building configuration "application"...
 source\app.d(154,5): Error: undefined identifier 'glViewport'
 source\app.d(157,13): Error: undefined identifier 'glfwWindowShouldClose'
 source\app.d(160,9): Error: undefined identifier 'glfwPollEvents'
 source\app.d(166,9): Error: undefined identifier 'glClearColor'
 source\app.d(167,9): Error: undefined identifier 'glClear'
 source\app.d(170,9): Error: undefined identifier 'glfwSwapBuffers'
 source\app.d(174,5): Error: undefined identifier 'glfwTerminate'
 dmd failed with exit code 1.
 myapp exited with code 2

 I see that dub has all the .d import files already placed in
 C:\Users\Me\AppData\Roaming\dub\packages\derelict-gl3-1.0.19\derelict-gl3\source\derelict\opengl3


 and
 C:\Users\Me\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3


 which should have all the definitions.  Is their an elegant way that I
 can tell dub to where these definitions? Or do I just have to brute
 force all the -I paths?

 I assume there is a slick way of specifying this because what happens
 when say glfw3-3.1.0 gets bumped up to 3.1.1?
Can you please post the dub file? Along with your source file. I have no idea what dub is even trying to do otherwise.
Sep 23 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 24 September 2016 at 02:33:22 UTC, WhatMeWorry wrote:

 I see that dub has all the .d import files already placed in
 C:\Users\Me\AppData\Roaming\dub\packages\derelict-gl3-1.0.19\derelict-gl3\source\derelict\opengl3

 and 
 C:\Users\Me\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3

 which should have all the definitions.  Is their an elegant way 
 that I can tell dub to where these definitions? Or do I just 
 have to brute force all the -I paths?
You don't have to specify the paths of dependencies. dub knows where they are and will make sure the compiler knows, too.
 I assume there is a slick way of specifying this because what 
 happens when say glfw3-3.1.0 gets bumped up to 3.1.1?
Then you execute 'dub upgrade' in the directory where your dub configuration resides. As long as you have the version of each dependency specified properly, it will do the right thing (TIP: use ~>x.x.x for versions, rather than >=x.x.x -- the former will restrict you to patch-level upgrades, e.g. 3.1.0 -> 3.1.1 and never 3.2, while the latter would happily go from 3.x -> 4.0 if it's available, often a breaking change). Did you import the derelict modules you're using in your app.d?
Sep 23 2016
parent reply WhatMeWorry <kheaser gmail.com> writes:
On Saturday, 24 September 2016 at 06:05:11 UTC, Mike Parker wrote:
 On Saturday, 24 September 2016 at 02:33:22 UTC, WhatMeWorry 
 wrote:

 I see that dub has all the .d import files already placed in
 C:\Users\Me\AppData\Roaming\dub\packages\derelict-gl3-1.0.19\derelict-gl3\source\derelict\opengl3

 and 
 C:\Users\Me\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3

 which should have all the definitions.  Is their an elegant 
 way that I can tell dub to where these definitions? Or do I 
 just have to brute force all the -I paths?
You don't have to specify the paths of dependencies. dub knows where they are and will make sure the compiler knows, too.
 I assume there is a slick way of specifying this because what 
 happens when say glfw3-3.1.0 gets bumped up to 3.1.1?
Then you execute 'dub upgrade' in the directory where your dub configuration resides. As long as you have the version of each dependency specified properly, it will do the right thing (TIP: use ~>x.x.x for versions, rather than >=x.x.x -- the former will restrict you to patch-level upgrades, e.g. 3.1.0 -> 3.1.1 and never 3.2, while the latter would happily go from 3.x -> 4.0 if it's available, often a breaking change). Did you import the derelict modules you're using in your app.d?
Well, my dub.sdl file has: dependency "derelict-gl3" version="~>1.0.19" dependency "derelict-glfw3" version="~>3.1.0" My app.d has: module app; import common.derelict_libraries; and derelict_libraries.d has: module derelict_libraries; import derelict.glfw3.glfw3; import derelict.opengl3.gl3; It's fine to import other imports, Right? I am trying to make a portable dub/dmd build environment on a flash drive for PC So the dub project is currently on a flash drive that is assigned the letter E: Naturally, this could change if the flash drive were moved to another PC. did have to write a little shim code to add environment["DFLAGS"] = r"-I..\"; so that the app.d import could find the derelict_libraries.d relative to the project directory. Like so: E:\projects\01_01_hello_window E:\projects\01_01_hello_window\source\app.d E:\projects\common\derelict_libraries.d So to summarize things, the derelict imports are fine. But how does dub tell dmd that it should looking for opengl imports at: C:\Users\Kyle\AppData\Roaming\dub\packages\derelict-gl3-1.0.15\source\derelict\opengl3 and glfw3's imports at: C:\Users\Kyle\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3 I'm desperately trying to avoid hard coding these paths. Because I want to use a lot more dub packages in the future.
Sep 24 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 24 September 2016 at 16:51:47 UTC, WhatMeWorry wrote:

 My app.d has:

 module app;
 import common.derelict_libraries;

 and derelict_libraries.d has:

 module derelict_libraries;
 import derelict.glfw3.glfw3;
 import derelict.opengl3.gl3;


 It's fine to import other imports, Right?
As long as they're public. Imports are private by default, meaning their symbols are only visible locally. Change it to: module derelict_libraries; public import derelict.glfw3.glfw3; public import derelict.opengl3.gl3;
 I am trying to make a portable dub/dmd build environment on a 
 flash drive for PC
 So the dub project is currently on a flash drive that is 
 assigned the letter E:
 Naturally, this could change if the flash drive were moved to 
 another PC.  did have to write a little shim code to add 
 environment["DFLAGS"] = r"-I..\";  so that the app.d import 
 could find the derelict_libraries.d relative to the project 
 directory. Like so:

 E:\projects\01_01_hello_window
 E:\projects\01_01_hello_window\source\app.d
 E:\projects\common\derelict_libraries.d
You can do that with dub without resorting to environment variables. Then you don't need to set it every time you move your flash drive to a different system. See the importPaths directive in the 'Build Settings' section of the documentation ([1] for JSON and [2] for SDLang).
 So to summarize things, the derelict imports are fine.

 But how does dub tell dmd that it should looking for opengl 
 imports at:

 C:\Users\Kyle\AppData\Roaming\dub\packages\derelict-gl3-1.0.15\source\derelict\opengl3

 and glfw3's imports at:

 C:\Users\Kyle\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3
Because dub created those paths and downloaded the source for those packages into those paths, it knows where everything is. When it invokes DMD, it uses the -I command line switch just like anyone else would.
 I'm desperately trying to avoid hard coding these paths. 
 Because I want to use a lot more dub packages in the future.
Well, good, because you don't need to hardcode them. [1] https://code.dlang.org/package-format?lang=json#build-settings [2] https://code.dlang.org/package-format?lang=sdl#build-settings
Sep 24 2016
parent WhatMeWorry <kheaser gmail.com> writes:
On Sunday, 25 September 2016 at 00:52:26 UTC, Mike Parker wrote:
 On Saturday, 24 September 2016 at 16:51:47 UTC, WhatMeWorry 
 wrote:

 [...]
As long as they're public. Imports are private by default, meaning their symbols are only visible locally. Change it to: module derelict_libraries; public import derelict.glfw3.glfw3; public import derelict.opengl3.gl3;
[...]
You can do that with dub without resorting to environment variables. Then you don't need to set it every time you move your flash drive to a different system. See the importPaths directive in the 'Build Settings' section of the documentation ([1] for JSON and [2] for SDLang).
 [...]
Because dub created those paths and downloaded the source for those packages into those paths, it knows where everything is. When it invokes DMD, it uses the -I command line switch just like anyone else would.
 [...]
Well, good, because you don't need to hardcode them. [1] https://code.dlang.org/package-format?lang=json#build-settings [2] https://code.dlang.org/package-format?lang=sdl#build-settings
Wow. That was the fix. Two "public" tokens. Thank you. I don't think I ever could of figured that out on my own. My debugging was completely off base; I was like a surgeon trying to perform an appendectomy by amputating a foot. Dub is nice. Just like Derelict.
Sep 25 2016