compiler-explorer/infra

Introduce compatibility list with compilers for library vendors and users

Opened this issue · 5 comments

partouf commented

Currently we offer only a list of which libraries are available to select from, and then eventually the user finds out if it actually works or not.
For the non-header-only libraries that we build, we have a way of actually knowing which commit was able to be built by which compilers.
We can offer a page of compatibility + incompatibility per library version or trunk commit.
The only problem is that once we rebuild for a new trunk commit, the information about the previous commit gets lost.

Perhaps we can also offer status badges? Not sure in what form though

Todos

  • Storage? -> DynamoDB table library-build-history
  • Proof of concept
  • Fill with data during library build-process
  • Make endpoint for a badge
  • Support Rust and Fortran
  • Turn into lambda on our api gateway
  • Make known to library maintainers
  • ?
partouf commented

Proof of concept @ https://conan.compiler-explorer.com/cpp_library_build_results/fmt/trunk/df249d8a

(Have manually marked armv8 clang trunk as failed, as all builds were succesful)

partouf commented

Ideas to expand this with:

  • Summarize failed builds
  • Add short list of things like 'Min. GCC supported', same for clang
  • Filter options by compiler type gcc/clang/icc/etc
  • Badge with Built with 99/100 compilers or something?
  • Github App to add to build checks per library commit?
  • When GH app we could potentially also show inprogress status during build process (now currently just stored as boolean true/false build succeeded) - but might be a lot of traffic?
  • Offer direct download options for the conan packages
partouf commented

Did some reading on https://shields.io which allow static text badges, but they're not great if you want to dynamically show something.

We could however make our own badges using their badge-maker npm library.

Question is what do we show?

partouf commented

One thing that is slightly problematic to provide is error logs when builds have failed. We have that for the Latest build that was done with a certain compiler, but even keeping a record of just that we have currently 3Gigs of errorlogs.

  • An option would be is to only show a log link if indeed we have that in our sqlite db.
  • Another option would be would be maybe to parse the error log and only show the error part of the entire log, but that's hard to manage to get right I would reckon given compiler output differences and the way cmake/ninja builds.
mattgodbolt commented

on my list to look at : thanks!!