DerelictBgfx not shipping core libs.

olivier henley via Digitalmars-d digitalmars-d at puremagic.com
Thu Nov 6 08:36:39 PST 2014


On Thursday, 6 November 2014 at 08:17:24 UTC, ponce wrote:
> Hi,
>
> First, I'd like to point out this question is better asked in 
> DerelictBgfx issues or digitalmars.D.learn, this NG is for 
> general D discussion.

Not agree. DerelictBgfx is one of the most interesting project D 
has to show off and therefore its usability becomes, IMHO, of 
general interest. Showing off is what makes the world turn so ...

> Shipping binaries with FFI bindings defeats software 
> distribution.

1. To what extent?
2. Let say this is plain right. Then why some FFI bindings 
package provides such binaries?

> I know this is annoying, but for others dynamic libraries 
> binaries are provided.

Not just annoying. From a user perspective it's like ... DoA.

> You might ask for bgfx to provide you with binaries with 
> automated builds.

No, they ship their makefile and are commited to a c/c++ 
ecosystem. We are breaking their "ways" by interfacing through 
another tech. They should not even know we exist... we are the 
leeches.

>> 2. Does the maintainer guaranty his wrapper will stay in sync 
>> with further changes of bgfx?

> I'm afraid, my plate is already full.
> bgfx interface changes without notice and frequently.
> You can still build an older version.

This is exactly my point. You had the libs built, on your system, 
in sync with the version of the binding you did. Why not push 
them along and basta! Done once and for all ... at least for one 
target.

Instead, every wanna be user has to figure out what tag of bgfx 
was used for the particular DerelictBgfx tag he aims to build, 
get equipped to make the original and suffer all the friction 
that such endeavour entails. -Welcome to a nice D show case 
project my friend.-

> I guess I should add in the README that you have to build bgfx 
> yourself for time being to avoid being let down.

Well, if I may answer through symmetric concerns ... constituting 
such a README should have been a matter of digitalmars.D.learn.


More information about the Digitalmars-d mailing list