DerelictBgfx not shipping core libs.

ponce via Digitalmars-d digitalmars-d at puremagic.com
Thu Nov 6 09:23:20 PST 2014


On Thursday, 6 November 2014 at 16:36:41 UTC, olivier henley 
wrote:
>> 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 
> ...

I'm glad you find it that interesting. That doesn't make this 
discussion relevant to most NG readers who are here to discuss D 
the language not some library issue.

>
>> Shipping binaries with FFI bindings defeats software 
>> distribution.
>
> 1. To what extent?

Mike Parker explained it better than I could.


> 2. Let say this is plain right. Then why some FFI bindings 
> package provides such binaries?

I wish you gave an example.


>> I know this is annoying, but for others dynamic libraries 
>> binaries are provided.
>
> Not just annoying. From a user perspective it's like ... DoA.

Responsibility of bgfx, not bindings to it.


>> 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.

There were PR since to update to latest API so these binaries 
would be outdated already.

This would be easier if bgfx had numbered releases and its API 
changed less.
What you _can_ do now is check the date where the API was last 
updated in DerelictBgfx

https://github.com/DerelictOrg/DerelictBgfx/commit/bf8bd88e1330bfbb6638214fd60a004506a9284d 
(it is mentionned in the commit for convenience)

Then you can build a bgfx from October 12th 2014 if the API has 
changed since.
It may very well be up-to-date, I don't know.


More information about the Digitalmars-d mailing list