www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DerelictBgfx not shipping core libs.

reply "olivier henley" <olivier.henley ubisoft.com> writes:
Hi,

May I ask what is the rational to not ship the core libs with the 
bgfx D wrapper? From my point of view it defies the main goal of 
using a D wrapper.

1. How can we promote the wrapper package if it implies to build 
not one, as of ... only bgfx, but two packages, bgfx and 
DerelictBgfx? Better stick to c/c++ then, and enjoy the path of 
least resistance. Don't you think?

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

3. Is there anything in the license refraining from shipping 
precompiled libs of the original package? (e.g. To my knowledge 
tkd publishes similar binaries (tcl and tk) without further legal 
complications.)

4. Am I missing something except the fact that a neophyte to the 
DerelictBgfx package is left with an incomplete build, of both 
the lib and the examples, an anemic README.md and a dead forum 
(http://dblog.aldacron.net/forum/index.php?topic=841.0)?

Thank you,

olivier
Nov 05 2014
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.

On Thursday, 6 November 2014 at 06:44:49 UTC, olivier henley 
wrote:

 Hi,

 May I ask what is the rational to not ship the core libs with 
 the bgfx D wrapper? From my point of view it defies the main 
 goal of using a D wrapper.


Shipping binaries with FFI bindings defeats software distribution.


 1. How can we promote the wrapper package if it implies to 
 build not one, as of ... only bgfx, but two packages, bgfx and 
 DerelictBgfx? Better stick to c/c++ then, and enjoy the path of 
 least resistance. Don't you think?


I know this is annoying, but for others dynamic libraries 
binaries are provided.
You might ask for bgfx to provide you with binaries with 
automated builds.

For other libraries, you will find that D is the path of least 
resistance (try using GLEW in C++ vs DerelictGL3 in D, the latter 
is easier).


 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.
That said, two times people have come up and updated the bindings 
already.


 3. Is there anything in the license refraining from shipping 
 precompiled libs of the original package? (e.g. To my knowledge 
 tkd publishes similar binaries (tcl and tk) without further 
 legal complications.)


I feel like this is a responsibility of bgfx to provide binaries.
DerelictSDL does not come with SDL binaries likewise, that would 
be insane.


 4. Am I missing something except the fact that a neophyte to 
 the DerelictBgfx package is left with an incomplete build, of 
 both the lib and the examples, an anemic README.md and a dead 
 forum (http://dblog.aldacron.net/forum/index.php?topic=841.0)?


I guess I should add in the README that you have to build bgfx 
yourself for time being to avoid being let down.
Nov 06 2014
parent reply "olivier henley" <olivier.henley ubisoft.com> writes:
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.
Nov 06 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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/bf8bd88e1330bfbb6638
14fd60a004506a9284d 
(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.
Nov 06 2014
parent reply "olivier henley" <olivier.henley ubisoft.com> writes:
On Thursday, 6 November 2014 at 17:23:21 UTC, ponce wrote:


 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


1. You make a tag for DerelictBgfx named x.x.x_shared_lib_sync 
and just deploy the libs for this tag's dub config file.

2. In the README.md you state that anyone who wants working 
precompiled shared libs for (this that that and that target) 
should depend on latest x.x.x_shared_lib_sync else they will have 
to build the original bgfx project.

Am I missing something?
Nov 06 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 6 November 2014 at 19:35:27 UTC, olivier henley 
wrote:

 On Thursday, 6 November 2014 at 17:23:21 UTC, ponce wrote:


 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


 1. You make a tag for DerelictBgfx named x.x.x_shared_lib_sync 
 and just deploy the libs for this tag's dub config file.

 2. In the README.md you state that anyone who wants working 
 precompiled shared libs for (this that that and that target) 
 should depend on latest x.x.x_shared_lib_sync else they will 
 have to build the original bgfx project.

 Am I missing something?


I can see how this is useful for Windows programmers but would 
strongly prefer to be completely separated from the bindings, in 
some kind of FTP/HTTP server. There would be a link in the 
README.md and you would upload builds there instead.
Nov 06 2014
parent reply "olivier henley" <olivier.henley ubisoft.com> writes:
On Thursday, 6 November 2014 at 20:08:24 UTC, ponce wrote:


 I can see how this is useful for Windows programmers but would 
 strongly prefer to be completely separated from the bindings, 
 in some kind of FTP/HTTP server. There would be a link in the 
 README.md and you would upload builds there instead.


yeah, it would be perfect. :)

I did not know for the Debian policy concerning dynamic libs. Thx.
Nov 06 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 6 November 2014 at 21:22:27 UTC, olivier henley 
wrote:

 I did not know for the Debian policy concerning dynamic libs.


Also, shipping binary builds for "Linux" without any further 
qualification is quite the headache anyway. Typically, you have 
to use some really old distro to avoid backwards compatibility 
issues with glibc et al., and then hope that newer distros don't 
ship any ABI-compatible changes to some of the used shared 
libraries.

You don't really know how much of a pain that can be until you've 
tried it. ;)

David
Nov 06 2014
parent "Laeeth Isharc" <laeethnospam spammenot_laeeth.com> writes:
It strikes me that the core question here may be one of the 
division of labour.  The person best suited to signing up for an 
ongoing commitment to maintain a whole load of different 
libraries across platforms/settings will only by the chancest 
fluke be the person who is suited to and enjoys writing bindings 
to these libraries in the first place.

There certainly is a large part of value in that last polishing 
effort that makes it not just easy, but a pleasure to install 
outside libraries.  That surely must be one of the things that 
has worked to Python's advantage.

Beyond pip, numpy itself, and the anaconda distribution, Python 
makes it super easy for the user who is perhaps capable but 
inexperienced with the language ecosystem to get started.  And 
quick wins are addictive once you start.  Perhaps D's market is 
different, but I wonder if something could be learnt and applied 
to the different situation of D.

[For example see Christopher Gohlke's work on building scipy 
module binaries here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/]

There are many fewer people in the ecosystem with D, which is why 
we are talking in the first place.  I suppose if we don't have 
the people then money will help, and I would guess a little would 
go a long way.  I am not in a position to provide this kind of 
support today, but hope to be so in a couple of years or so.

But I certainly think the idea of making the whole experience 
much easier and more quickly gratifying might be one worth 
considering.  (I am sure Russell will correct me on the details).


Laeeth.
Nov 06 2014
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 11/6/2014 3:44 PM, olivier henley wrote:

 Hi,

 May I ask what is the rational to not ship the core libs with the bgfx D
 wrapper? From my point of view it defies the main goal of using a D
 wrapper.


First, let's get some terminology straight. There are no "wrappers" in 
Derelict. The Derelict packages are all "bindings," meaning they are 
one-to-one translations (as much as possible) of the original library. A 
wrapper is something that provides functionality on top of the binding 
and makes it more like the host language.

As the guy who created Derelict in the first place, I can give you a 
simple rationale behind not distributing the binaries -- it is not my 
responsibility. I'll give you three even better reasons now :)

If I start shipping the C shared libraries for every binding in 
Derelict, then,

1) I must consider all supported platforms (Windows, Mac, Linux, 
FreeBSD, OpenBSD, and wherever people are using GDC and LDC these days). 
Would I be expected to provide prebuilt binaries for each platform?

2) I must also consider the multiple options each library can be 
configured to support. For example, the Open Dynamics Engine (to which 
DerelictODE binds) can be compiled to use doubles or floats. Would I be 
expected to provide prebuilt binaries for each?

3) In order to support 1 and 2 above, I would then have to make time to 
either compile or acquire pre-built binaries for each supported platform 
and each compile time configuration for each C library to which Derelict 
binds. To that I say, no thanks.



 1. How can we promote the wrapper package if it implies to build not
 one, as of ... only bgfx, but two packages, bgfx and DerelictBgfx?
 Better stick to c/c++ then, and enjoy the path of least resistance.
 Don't you think?


I've been maintaining Derelict for 10 years. In all that time, you are 
the first person to ever bring this up that I've seen. That tells me 
that it's a non-issue.

Some C library projects provide prebuilt binaries, some don't. It's 
entirely up to you to learn what you need to know about the libraries 
you need to use, including how to get them. Derelict just enables access.


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


ponce is the primary maintainer of DerelictBGFX and has provided his own 
answer, but I would add that anyone can post a pull request to github 
for any of the binding packages in DerelictOrg, including the Bgfx 
binding. Or, at the very least, create an issue with a request to 
update. So if any of them fall behind, it's an easy problem to solve. 
Since I moved Derelict to github a few years back, keeping everything up 
to date has been smooth sailing.


 3. Is there anything in the license refraining from shipping precompiled
 libs of the original package? (e.g. To my knowledge tkd publishes
 similar binaries (tcl and tk) without further legal complications.)


The answer to this is no, but it's irrelevant.


 4. Am I missing something except the fact that a neophyte to the
 DerelictBgfx package is left with an incomplete build, of both the lib
 and the examples, an anemic README.md and a dead forum
 (http://dblog.aldacron.net/forum/index.php?topic=841.0)?


It is not an incomplete build. It provides everything it is supposed to. 
The Derelict bindings enable you to use C libraries in D, and nothing 
more. If you need examples on how to use Bgfx, you need to be talking to 
the Bgfx maintainer (you can find the link in the first line of the 
README). Everything you need to know to use DerelictBGFX is right there 
in the anemic README. The forum link shouldn't be there and should have 
been replaced with a link to [1]. When I was updating all of the READMEs 
to point to the new location, I overlooked ponce's bindings and no one 
had reported it. That one's on me.

I'm working on a comprehensive set of documentation for all Derelict 
packages [2] that will be more friendly to those who aren't sure what's 
going on, but it is not going to be a tutorial on compiling C libraries, 
nor will it provide examples on how to use any of the C libraries it 
binds to. That's well beyond the scope of the project. At present, there 
is enough there to supersede the page at [1] and to replace the 
information from the dead forum link. All of the Derelict READMEs will 
eventually point to it when it is complete.

[1] http://dblog.aldacron.net/derelict-help/using-derelict/
[2] http://derelictorg.github.io/
Nov 06 2014
parent reply "olivier henley" <olivier.henley ubisoft.com> writes:
On Thursday, 6 November 2014 at 12:31:32 UTC, Mike Parker wrote:


 First, let's get some terminology straight. There are no 
 "wrappers" in Derelict. The Derelict packages are all 
 "bindings," meaning they are one-to-one translations (as much 
 as possible) of the original library. A wrapper is something 
 that provides functionality on top of the binding and makes it 
 more like the host language.


Then I'm not the only one in need to be put straight:

"Binding generally refers to a mapping of one thing to another. 
In the context of software libraries, bindings are wrapper 
libraries that bridge two programming languages so that a library 
written for one language can be used in another language". 
(http://en.wikipedia.org/wiki/Language_binding)


 If I start shipping the C shared libraries for every binding in 
 Derelict, then,

 1) I must consider all supported platforms (Windows, Mac, 
 Linux, FreeBSD, OpenBSD, and wherever people are using GDC and 
 LDC these days). Would I be expected to provide prebuilt 
 binaries for each platform?


1. Windows is a good start.
2. Nobody said you had to provide all of them.
3. We can help. Just myself, I could provide Linux and Windows. 
It makes for about 80% of all computers in the world.


 2) I must also consider the multiple options each library can 
 be configured to support. For example, the Open Dynamics Engine 
 (to which DerelictODE binds) can be compiled to use doubles or 
 floats. Would I be expected to provide prebuilt binaries for 
 each?


Playing cat and mouse here. For a show case, a prototype or any 
other normal use, nobody cares if its compiled to use doubles or 
floats. Choose doubles to stay on the safe side and the guy who's 
really needy for floats will roll his own build of ODE.

It's all common sense.


 I've been maintaining Derelict for 10 years. In all that time, 
 you are the first person to ever bring this up that I've seen. 
 That tells me that it's a non-issue.


1. Probably because most people outside the D enthusiasts just 
gave up.
2. Does someone recall a post where a D user advised, in essence, 
to not take the Derelict's path as it was much more involved than 
it may look... or am I fabulating here?


 Some C library projects provide prebuilt binaries, some don't. 
 It's entirely up to you to learn what you need to know about 
 the libraries you need to use, including how to get them. 
 Derelict just enables access.


I have noooooo problem building the original packages but I 
definitely prefer having sex with my girlfriend.

I just don't see the point to not share the most common target 
dependencies libs. Therefore the examples can run out of the box 
for most people and some super cool project can be show cased for 
D rapidly. This leads to hooking. That's it that's all and this 
is the key.

-"Check body, install dmd, install dub, install DerelictBgfx, 
build and run the examples. Bang! Now check the code how its lean 
and clean."
-"Wow, for sure my next rendering project will be in D dude!"

We need people to get hook. We need people to "feel" the 
productivity, the performance, the cleverness, the smoothness and 
clarity of D. There is many contender out there and the window of 
opportunity you have to sell your tech to someone is very thin. 
Look at what they did for the launch of Swift. Everyone I know 
wants to get a hand on the Bret Victor-ish demo. Is it core?.. 
nahh, it's a simple demo of what you can achieve. It makes you 
wonder and adhere and download.

Then, once hooked, new user will find the motivation that most of 
us on this forum share to rebuild ODE for the sake of having 
calculations done in floats and not doubles.

No, instead here we are shown no flexibility whatsoever in the 
name of the purity of what should be a proper packaging of an 
orthodox binding software layer... and the simple pretention to 
ask why it could not be done otherwise, like others did with 
sensible vision, slowly drift toward an unstable activity.


 I'm working on a comprehensive set of documentation for all 
 Derelict packages [2] that will be more friendly to those who 
 aren't sure what's going on


Good to hear.

olivier
Nov 06 2014
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
 I just don't see the point to not share the most common target 
 dependencies libs. Therefore the examples can run out of the 
 box for most people and some super cool project can be show 
 cased for D rapidly. This leads to hooking. That's it that's 
 all and this is the key.


Common libraries binaries can usually be found on their own site.
The best we can do it provide a link.

You had this problem with bgfx specifically because it's 
bleeding-edge and relatively unknown, and has no binary releases. 
I'm pretty sure when it's more established it will have easy 
channels to get it ready-made.

I think there is a misunderstanding: bgfx are kind of cool, but 
they were only ported for basic testing of the bindings, and 
maybe should be removed now to avoid rot.


 -"Check body, install dmd, install dub, install DerelictBgfx, 
 build and run the examples. Bang! Now check the code how its 
 lean and clean."


I checked The .NET bindings does this indeed, they commited a 
build in their ngfx bindings. The Go one did not.

This can't fly if you target non-Windows systems. Eg, in Debian 
it is disallowed by policy to ship .so dependencies with your 
software in order to build it.
Nov 06 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
 I think there is a misunderstanding: bgfx _examples_ are kind 
 of cool, but they were only ported for basic testing of the 
 bindings, and maybe should be removed now to avoid rot.
Nov 06 2014
prev sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Thursday, 6 November 2014 at 19:12:37 UTC, olivier henley 
wrote:

 1. Windows is a good start.
 2. Nobody said you had to provide all of them.
 3. We can help. Just myself, I could provide Linux and Windows. 
 It makes for about 80% of all computers in the world.


If you would like to compile and host Linux and Windows binaries 
for all Derelict packages somewhere, go for it. I'm not going to.



 Playing cat and mouse here. For a show case, a prototype or any 
 other normal use, nobody cares if its compiled to use doubles 
 or floats. Choose doubles to stay on the safe side and the guy 
 who's really needy for floats will roll his own build of ODE.

 It's all common sense.


Then perhaps my sense is uncommon. People *will* care if it uses 
floats or doubles. They make that decision when they are setting 
up the build process for their apps and they will need the 
appropriate binary. If I provide only one type, I'm alienating 
those who want the other. Better for everyone to visit the 
project site of the C library and get what they want from there.


 I have noooooo problem building the original packages but I 
 definitely prefer having sex with my girlfriend.


And you suppose I have nothing better to do than to compile 
multiple binaries for over a dozen projects every time they put 
out a new release or, as in the case of Bgfx, update their repo? 
My time is rather more valuable to me than that.


 I just don't see the point to not share the most common target 
 dependencies libs.


Because it's beyond the scope of the project. I will not 
distribute any precompiled C binaries with any Derelict packages. 
Even if I had copious amounts of free time and a room full of 
computers running multiple operating systems, I wouldn't do it. 
When the documentation is complete, Derelict users will have all 
the information they need to go out and get their hands on the 
libraries they need. Beyond that, they are on their own.
Nov 06 2014
next sibling parent reply "Laeeth Isharc" <laeethnospam spammenot-laeeth.com> writes:
On Friday, 7 November 2014 at 05:33:11 UTC, Mike Parker wrote:


 And you suppose I have nothing better to do than to compile 
 multiple binaries for over a dozen projects every time they put 
 out a new release or, as in the case of Bgfx, update their 
 repo? My time is rather more valuable to me than that.


 I just don't see the point to not share the most common target 
 dependencies libs.


 Because it's beyond the scope of the project. I will not 
 distribute any precompiled C binaries with any Derelict 
 packages. Even if I had copious amounts of free time and a room 
 full of computers running multiple operating systems, I 
 wouldn't do it. When the documentation is complete, Derelict 
 users will have all the information they need to go out and get 
 their hands on the libraries they need. Beyond that, they are 
 on their own.


Exactly the point...  It probably does make sense for some other
set of people to do these tasks (provide bandwidth, organize
somewhat automated build/publish process, fix build problems,
deal with problems/minor support), but it's unreasonable to
expect the guy writing the bindings to do so.

(It makes sense because in the world we live in small frictions
have big cumulative effects.  I know in Python I can try out a
library by just typing pip install foo - and it's a surprise when
it doesn't just work.  Acknowledging that I speak outside of my
core expertise, I think there would be value in D working to
provide a similar experience).

What I should so is volunteer to help, but at this moment I
simply don't have the capacity (on the resource front I hope that
may change in time).  I would very much like to, though.

There was some discussion previously by Andrei and Walter in
another thread about how people could help.  Do you think it
makes sense to have a link on front page of dlang saying "how you
can help dlang grow"  And then have a list of strategic projects,
and a list of tactical tasks.


Laeeth.
Nov 07 2014
parent "Mike Parker" <aldacron gmail.com> writes:
On Friday, 7 November 2014 at 14:33:09 UTC, Laeeth Isharc wrote:


 What I should so is volunteer to help, but at this moment I
 simply don't have the capacity (on the resource front I hope 
 that
 may change in time).  I would very much like to, though.


Gathering together multiple binaries for multiple platforms for 
every library to which Derelict binds and then keeping them up to 
date would be a fairly time-intensive effort unless it could be 
completely automated. Like I told the OP, in the 10 years I've 
been maintaining Derelict this hasn't been a source of complaint 
until now. Given how tiny the problem is in relation to the 
amount of effort required to solve it, I think there are better 
ways to use your time in helping D.

Besides, some of the bound libraries are commonly installed on 
many systems already and others make binaries available for 
multiple platforms. Only a few of them require compilation. The 
package that started this whole discussion is a bit of an anomaly 
right now in the Derelict universe, because it's implemented 
against a moving target rather than a stable release (simply 
because there are no stable releases of Bgfx). Perhaps the 
included examples contributed to the problem as well (no other 
Derelict package includes examples), which I can see giving an 
impression that DerelictBgfx is something more than it is. The 
README also fell out of sync with the other packages.

As I see it, the solution is to remove the examples from 
DerelictBgfx, enhance the READMEs in every package and finish the 
docs. As long as users have clear instructions in the docs that 
they need to obtain the binaries themselves, I don't believe more 
need be done. Of course, I can't make them read the docs, which 
btw is something they would still need to do if you or someone 
else hosted all those binaries, else they wouldn't know where to 
find them.


 There was some discussion previously by Andrei and Walter in
 another thread about how people could help.  Do you think it
 makes sense to have a link on front page of dlang saying "how 
 you
 can help dlang grow"  And then have a list of strategic 
 projects,
 and a list of tactical tasks.


Discussion along those lines has come up now and again. There may 
be something over at the Wiki. Personally, I'm happy to do my bit 
by keeping Derelict alive and in semi-decent health and writing 
an occasional blog post when the mood strikes. I'll leave ideas 
about how to manage dlang contributions to others.

That said, I would like to see someone at some point step up to 
serve as a sort of Community Manager (or Lieutenant as Andrei 
would say), someone who would keep a list of key areas where D 
and and its satellite projects need help, tracking progress and 
updating the list as necessary. Without someone actively 
overseeing such a list, it's just going to stagnate (especially 
if it's on the dlang front page, but also on the Wiki).
Nov 07 2014
prev sibling parent reply "olivier henley" <olivier.henley ubisoft.com> writes:
On Friday, 7 November 2014 at 05:33:11 UTC, Mike Parker wrote:


 Because it's beyond the scope of the project. I will not 
 distribute any precompiled C binaries with any Derelict 
 packages. Even if I had copious amounts of free time and a room 
 full of computers running multiple operating systems, I 
 wouldn't do it. When the documentation is complete, Derelict 
 users will have all the information they need to go out and get 
 their hands on the libraries they need. Beyond that, they are 
 on their own.


Ok, you are right not to distribute any binaries. Your project 
has a precise scope and covers many different packages. It is 
coherent "as is".

Guys like me and Laeeth should organize around your work to 
deliver a smooth experience when possible. E.g. provide dlls 
through separate means for windows like Ponce suggested.

Nevertheless I feel we should be told upfront about the 
implications of using your package in the context that you can't 
and won't deliver dependencies like others do. By upfront I mean 
in an explicit way, limit as a warning.

Sincerely,

olivier
Nov 07 2014
next sibling parent "olivier henley" <olivier.henley ubisoft.com> writes:
Ponce already added a -Warning- on the DerelictBgfx readme.

Super, thx. This way the next guy like me will go build bgfx 
before attempting to blindly make DerelictBgfx examples run...
Nov 07 2014
prev sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Friday, 7 November 2014 at 18:46:50 UTC, olivier henley wrote:


 Nevertheless I feel we should be told upfront about the 
 implications of using your package in the context that you 
 can't and won't deliver dependencies like others do. By upfront 
 I mean in an explicit way, limit as a warning.


Back in the Derelict 2 days I had a good bit of documentation 
written up [1]. Despite that, I still had people coming to the 
forums looking for help about things that were covered clearly in 
the docs. Others were getting help elsewhere. Few people read 
documentation in practice (which is the reason I put it off to 
the last when working on Derelict 3 and, now, DerelictOrg). 
Still, I never had anyone raise an issue about not distributing 
the binaries. As such, it's never occurred to me that it could be 
an issue.

I don't think any "warnings" about my not distributing binaries 
are necessary. You make it sound as if I'm doing something 
extremely out of the ordinary. If I were distributing a game 
framework or some such, you might have a  point. But for a 
collection of bindings, I just don't agree.

At any rate, I'm soon to add a section to the docs at [2] about 
using Derelict at runtime. I'll include a line explaining that 
the shared library binaries for the C libraries need to be 
obtained separately. The package-specific documentation will 
include links to the project pages, as the READMEs already and 
will continue to do. I'll also add a line to the READMEs, 
instructing the user to obtain the shared libraries separately. 
That should be sufficient.

[1] 
http://svn.dsource.org/projects/derelict/branches/Derelict2/doc/index.html
[2] http://derelictorg.github.io/using.html
Nov 07 2014
next sibling parent "olivier henley" <olivier.henley ubisoft.com> writes:
On Saturday, 8 November 2014 at 04:15:22 UTC, Mike Parker wrote:


 I don't think any "warnings" about my not distributing binaries 
 are necessary. You make it sound as if I'm doing something 
 extremely out of the ordinary. If I were distributing a game 
 framework or some such, you might have a  point. But for a 
 collection of bindings, I just don't agree.



2. At the time, the bgfx D binding package included examples and 
presented no clarification whatsoever about dependencies.
2. warning cost a couple of octets on the Readme and clarify 
things once and for all to anybody coming from any background.
3. Ponce already reacted proactively 2 days ago.

I already fixed the bgfx bindings examples to be in sync with the 
latest bgfx package, submitted a pull request and send win libs 
to Ponce to *maybe* find a way and share for windows users.

Adding that I gave you my hand two posts ago, now please don't 
take my arm.

If you don't want to make the distance, the discussion is over... 
I'm serious.

Sincerely,

olivier
Nov 08 2014
prev sibling parent "olivier henley" <olivier.henley ubisoft.com> writes:
On Saturday, 8 November 2014 at 04:15:22 UTC, Mike Parker wrote:


 I'll also add a line to the READMEs, instructing the user to 
 obtain the shared libraries separately. That should be 
 sufficient.


Just checked back and ran across that one. I therefore conclude 
this is your way to put water in your wine.

See that's the problem, why do you argue over warning, no 
warning, just a line, bold not bold, h1, h5, in esperanto... 
whatever? I just proposed you make it clear.

Now if a one liner is clear to you so be it, but then I wonder 
why we invented formatting and keywords.

That said, if in the future, I come across one guy acknowledging 
he missed that line and someone tells him to "RTFM" I'll be the 
first to step in and put the records straight.

Do we have a deal?
Nov 08 2014