Providing GCC to user

[trixtan]

Hi!
I am exploring CDT.cloud, I am in the phase where I have to understand how the architecture works. I tried to build and run the blueprint, and from what I understand the user is required to have GCC and CMake installed in the host system to build a C/C++ project.

What would be the strategy to implement, if I wanted to provide the user with a specific GCC and CMake version? The use case is the user shall not need to "setup" its development Environment, but everything gets configured for him by the IDE.

Thank you,
Enrico

[planger]

Hi Enrico,

Thank you for your interest in CDT.cloud!

First of all, there are fundamentally two options for shipping a product based on CDT.cloud:

1. As a cloud service
   When CDT.cloud is shipped as a cloud service, no installation on the local user machine is required as the development environment is accessed by users via their browser. The CDT.cloud backend is executed in a container, which has all build tools, such as GCC and CMake, already installed in a particular version (see also an example dockerfile). To manage and spin up the containers for your users, you'll need to provide a kubernetes cluster and use a workspace hosting solution, such as Eclipse Che or Theia.cloud.
2. As a desktop tool
   Alternatively you can ship a CDT.cloud-based product as a desktop application with Electron. In this case, no further infrastructure or workspace hosting solution is needed, but CDT.cloud as well as the build tools it requires have to be installed on the local machine of your user.

Please note that without much additional code, you can also do both, option 1 and option 2.

For option 2:
There are different approaches on how to ship those build tools alongside CDT.cloud and there is no off-the-shelf solution for that, as it heavily depends on the use case:
How much control do your users need to select and install build tools, do they need those tools to be installed globally on their system or not, the selection of tools depend a lot on the specific toolchain and thus also their installation procedure varies, etc..

Common approaches for setting up the system dependencies in case of option 2 are:

• Make CDT.cloud test on startup whether the required tools, like GCC, are available on the system and if not prompt the user if they want to install it. An example for that can be found in clangd-vscode for the clangd installation on the system (see its install.ts)
• Provide a dedicated installer that installs not only CDT.cloud itself, but also its required build tools. This is what many larger commercial tool vendors are doing for their specific toolchains.
• Run the CDT.cloud backend in docker. This is similar to option 1 above, but instead of hosting the containers in kubernetes, the container runs locally. This is pretty neat in terms of flexibility, but requires your users to have docker installed.

Most of what I mentioned above is not particularly specific to CDT.cloud but rather true for any tool built on Theia, which is the tool platform also CDT.cloud uses. Theia can be used to create a desktop tool, as well as a cloud tool, basically from the same code base. More information can be found at https://theia-ide.org. On that page you can also try Theia online (which uses a hosting provided by Theia.cloud) or download a built desktop app.

Please feel free to share more information about your particular use case! This could enable us to give more concrete suggestions.

I hope this helps!

Best wishes,

Philip

[trixtan]

Hi Philip!

thank you for the great explanation!
It is extremely interesting to me. I will give you a bit of my background, this should probably explain a bit better what my use case is.

I work for Infineon Technologies, and I am the lead developer of AURIX Development Studio, which is our IDE for the AURIX platform (https://www.infineon.com/cms/en/product/promopages/aurix-development-studio/).
AURIX Microcontrollers are quite powerful and challenging for a tool developer, because they contain multiple cores with different architecture. The TC3 family for example, contains ARM, 8051, TriCore cores and a core with BOSCH proprietary architecture. They are very complex devices, and not every developer is interested in using all cores. So our tools need to be modular, but also powerful enough to support multiple architectures in the same project on demand.
AURIX Development Studio is a CDT based IDE, which makes use of the Managed Build and provides everything it can provide to ease the user experience.
In other words, the user needs just to install one package, and everything is ready. This requirement is necessary because most of the users are able to write code for the device, but don't really understand how a dev environment works. A lot of them doesn't even know what GCC is, or the difference between compiler and assembler.

This is why I am very interested in providing an all-in-one solution. By the way, the Managed Build was my second question. I did not find anything in that direction already in the CDT.cloud. Am I right or did I just miss it?

[trixtan]

By the way, I will be at the EclipseCon this year. If you are also there and you have time we could have a chat about this topic.

[planger]

Thank you for the additional context, that certainly helps to understand your goals and makes a lot of sense!

I'll be attending EclipseCon and I'd be happy to chat! EclipseSource has a conference booth, so please stop by anytime and let's chat. Looking forward to meeting you in person!

You are right that there is no such thing like CDT's managed build in CDT.cloud. In CDT, one of the main reasons for needing the managed build is to provide the CDT Indexer with all information needed to correctly interpret the sources.
In the technology stack that is typically used in the context of CDT.cloud, this is different. Most of the adopters use clangd to provide language services and editing support. Clangd uses a compilation database in the form of the compile_commands.json, which captures the build commands, inlcuding flags, symbols, compiler options, etc. This compilation database is usually generated by the build system (such as CMake), but can also be captured e.g. with Bear or created by come a custom component. Based on the information of this compilation database, the language service can derive how to interpret the sources, build an AST and an index for providing language editing support. So for providing language editing support, a mechanism like CDT's managed build isn't needed and this approach removes a lot of complexity in the development environment.

However, a lot depends on the concrete use case. So best we chat at EclipseCon in more detail. Looking forward to our conversation!

[trixtan]

Thank you for the eye opening explanation. Next step I will look into clangd.

See you in Ludwigsburg!

Enrico