mirror of
https://github.com/compiler-explorer/compiler-explorer.git
synced 2025-12-27 10:33:59 -05:00
f2c1e0bd31
* The Grand Reformat - everything made prettier...literally - some tweaks to include a few more files, including documentation - minor changes to format style - some tiny `// prettier-ignore` changes to keep a few things the way we like them - a couple of super minor tweaks to embedded document types to ensure they format correctly
75 lines
4.0 KiB
Markdown
75 lines
4.0 KiB
Markdown
# Compiler Explorer Road Map
|
|
|
|
This document is an attempt to capture thoughts on the future direction of Compiler Explorer. Last updated May 2021.
|
|
|
|
## Areas to improve
|
|
|
|
### Support more languages and compilers
|
|
|
|
A number of the open issues are to add more languages, libraries and compilers. Continuing to make it easier for others
|
|
to submit PRs to add new compilers is very important. This has improved, but not all compilers are installed using the
|
|
new approach. There's documentation on [adding a compiler](AddingACompiler.md),
|
|
[adding a new language](AddingALanguage.md) and [adding a library](AddingALibrary.md).
|
|
|
|
### Multiple file support
|
|
|
|
As the site is getting used more and more, and in different ways to the initial intention, we would benefit from being
|
|
able to support multiple files in compilations. That is, C++ source files, and header files compiled together, or even
|
|
multiple C++ files compiled and linked together. This would let us showcase technologies like link-time optimization, or
|
|
C++ modules.
|
|
|
|
### Code quality and testing
|
|
|
|
A project like Compiler Explorer thrives best when many people can easily contribute. There are many languages,
|
|
libraries, use-cases, and visualisations that the "core" team doesn't have experience with. In order to remain
|
|
supportable and keep serving various programming communities, we need to make the project easy to work with. We can
|
|
improve code quality (e.g. move to transpiling from Typescript or similar to give us stronger types), testing
|
|
(increasing coverage, adding client tests), and documentation to make it easier to on-board new contributors and keep it
|
|
easy to support existing code.
|
|
|
|
## Considerations
|
|
|
|
### Tensions
|
|
|
|
There's an inherent tension between the standalone, run-it-yourself version of CE and the scalable, AWS-backed CE
|
|
instance. Care must be taken to keep the standalone version usable.
|
|
|
|
### Priorities
|
|
|
|
Above all, the priority is to keep the main CE site up, stable and dependable. That also means that URLs should live
|
|
forever once they are created, which places a burden on us to keep existing compilers and libraries available forever.
|
|
|
|
### Non-goals
|
|
|
|
Compiler Explorer will remain open-source and non-commercial. There are no plans at all to add "freemium" content. We do
|
|
have a Patreon site, Github sponsors, Paypal donations, and some corporate sponsors. Funds from these source help
|
|
support the cost of running the servers, and incentivize the core team. Previously our goal was to remain "ad-free",
|
|
that has been relaxed slightly to allow up to three company sponsor logos visible at the top right of the screen.
|
|
|
|
## Goals
|
|
|
|
### 2021 goals
|
|
|
|
- **Login support**. Support logging in to the site with GitHub, Google, etc. We will _never_ force you to log in for
|
|
basic features, and of course will update the Privacy Policy. I won't be selling anything to do with user info etc,
|
|
either: Logging in will be purely used to make _your_ life easier and allow you to manage things like shared settings
|
|
and configuration, listing short URLs you've created (and potentially being able to remove them); and _maybe_ being
|
|
able to make user-named short URLs (e.g., "godbolt.org/u/mattgodbolt/ctad-example"). This goal is a personal pet
|
|
project of [Matt's](http://github.com/mattgodbolt/).
|
|
- **Multi-file support**. Multiple file compilation units to open the door to seeing LTO and maybe modules. This may
|
|
include being able to use a `CMake` file to build things.
|
|
- **Modernising the codebase**. Moving the codebase to TypeScript, or something similar that will allow us to worry less
|
|
about differences between front-end and back-end code (old Javascript versions), and help us attract more people to
|
|
the project.
|
|
- **More compilers and libraries**. Plus finishing off the last stragglers of installation.
|
|
|
|
### Prior years' goals
|
|
|
|
#### 2020
|
|
|
|
**Was**: Finally tackle small screen device support.
|
|
|
|
**How did we do?**: a tiled, single-page read-only view was implemented. Our mobile support is about the best we could
|
|
hope for given the limitations of space and our current reliance on Microsoft's Monaco editor, which doesn't support
|
|
mobile at all.
|