can we make glfwInit optional?

[timotheecour]

can we make glfwInit optional?

[ljubobratovicrelja]

(eg on hosts where we can't have valid X server connection )

I believe in that case you wouldn't need dcv:plot module at all, right? If that is so, you could just link against dcv:core and dcv:io. Would that do?

[timotheecour]

sorry, that's just not a good solution, suppose you have some complex code that is intended to work both with and without plotting depending on platform / architecture support. Inserting static if(has_gl) or version(with_gl) everywhere is too much trouble for client code.
Instead, we should allow runtime loading on demand via dlopen+friends of C shared libraries as done in other projects. I can provide references if needed.

Side question: is there a simple way to get libgl on ubuntu?

[ljubobratovicrelja]

I'm sorry, I'm not sure I understand the situation completely. But if you've encountered this in a production-like environment, than it is clear this should be done. So, how do we do this? What do we do with the rest of the dcv.plot code in runtime if glfwInit fails?

[ljubobratovicrelja]

What do we do with the rest of the dcv.plot code in runtime if glfwInit fails?

(thinking out loud here) We could throw an exception at any call that depends on glfwInit?

[timotheecour]

Exactly. Currently, it wont even allow code imports plotting but doesnt call plotting functions. With this, it will allow importing such code and all is fine so long plotting isnt used.

[ljubobratovicrelja]

Awesome. @9il I believe we're OK with throwing Exceptions in the dcv.plot module. This is definitely a higher-level module with no (or very little) performant-critical code inside. Do you agree with this solution, or do you have some other proposition to solve it?

[ljubobratovicrelja]

Side question: is there a simple way to get libgl on ubuntu?

Sorry for ignoring this, didn't catch it before. Do you mean glfw? If so sudo apt-get install glfw3 will do, I think.

[timotheecour]

No, libgl. Theres a recursive dub dependency on libgl (maybe after brew install ffmpeg, i forgot where it arose from)

[ljubobratovicrelja]

Isn't libGL.so present by default? I believe even unity depends on it :). Anyhow, if you're failing to link against it, maybe it's not named the way dcv's dub.json expects it. Sorry, I'm not much of a help here, since I don't have ubuntu machine. Hope you'll manage.

[timotheecour]

That's another point: linker is case sensitive and libGL may be present but dub.json specifies libgl

[timotheecour]

Supporting Ubuntu would be great, given its popularity... parallels or virtualbox are pretty easy to setup :)

[9il]

Awesome. @9il I believe we're OK with throwing Exceptions in the dcv.plot module. This is definitely a higher-level module with no (or very little) performant-critical code inside. Do you agree with this solution, or do you have some other proposition to solve it?

Agreed

[9il]

#109

[ljubobratovicrelja]

Agreed

Awesome! @timotheecour I'll try fix this by the end of the day.

[ljubobratovicrelja]

That's another point: linker is case sensitive and libGL may be present but dub.json specifies libgl

What's really interesting is that I've developed much of dcv on ubuntu. And that gl linking that was put there in dub.json seemed to be working. :) Anyhow, hope your linking is fine after Ilya's fix. And thanks for pointing this out!

[timotheecour]

tracked in #113 so closing this