On Saturday, September 8, 2018 7:28:53 AM MDT Nicholas Wilson via Digitalmars-d wrote: > On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote: > > Again, this strongly suggests the idea I've mentioned a few > > times now: *all* packages on code.dlang.org needs to be run > > through a CI tester, and success/failure to compile should be > > reported back to dlang.org somehow. Then in the search results > > and in the package's home page, there should be a > > prominently-displayed notice of which compiler versions work / > > don't work with the package. > > > > This gives users the information they need to make the right > > decision (e.g., the last known compiler that compiles this > > package is 2.060, so don't bother, move on.). > > > > And this *must* be automated, because nobody has the time or > > energy to manually test every package against every known > > compiler release and manually update code.dlang.org. And doing > > it manually tends to quickly get out of date, not to mention > > the chance of human error. > > > > > > T > > How would this work for packages that cannot be built by DMD? Or > that have no CI infrastructure but are maintained? *cough* > DCompute *cough*
A related issue is projects that have dependencies outside of D itself - for instance, a project that wraps GTK or Qt or something C or C++ library that is on many systems but which isn't guaranteed to be present. It would be trivial to end up with packages being marked as unmaintained or not even working at all when in reality, they work just fine. It's just that they require more than just dub and the D compiler to work. These problems aren't necessarily insurmountable, but they do complicate the things. And while we do want to provide better information about what is and isn't working and maintained, we also don't want to be marking projects as not working when they actually work just fine - Jonathan M Davis
