Re: DerelictBgfx not shipping core libs.
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. 1. bgfx bindings for C# includes bgfx binaries for windows. 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
Re: DerelictBgfx not shipping core libs.
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?
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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
Re: DerelictBgfx not shipping core libs.
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... and get uber-@#!x%#%^.
Re: DerelictBgfx not shipping core libs.
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
Re: DerelictBgfx not shipping core libs.
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).
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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/
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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 noo 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
Re: DerelictBgfx not shipping core libs.
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?
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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
Re: DerelictBgfx not shipping core libs.
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.
Re: DerelictBgfx not shipping core libs.
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 noo 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.
DerelictBgfx not shipping core libs.
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
