Introduce compatibility list with compilers for library vendors and users

[partouf]

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]

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]

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]

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]

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]

on my list to look at : thanks!!

[partouf]

example of a Saturday build where libraries are built with all capable compilers https://conan.compiler-explorer.com/cpp_library_build_results/fmt/trunk/385c01dc

there are more errors here because not all compilers are configured correctly/can't actually build binaries - leading to: there might be too many compilers to be a useful overview as it's almost never the actual library code's fault that the build fails in these cases

[mattgodbolt]

Is there anything special about the builder instance or could we consider using the ce-ci instances (not as part of this, just wondering out loud)

[mattgodbolt]

example of a Saturday build where libraries are built with all capable compilers https://conan.compiler-explorer.com/cpp_library_build_results/fmt/trunk/385c01dc

Looks great!

[mattgodbolt]

Agreed re: parsing error logs: perhaps tail -20 is "good enough" though?