Description of the Core Build System.

[ewaterlander]

This is an initial description of the Core Build System for the user manual.
I think it should be placed just before the explanation of creating CMake and Makefile projects.

[ewaterlander]

Hi @jonahgraham , @betamaxbandit , and @jld01 ,
here is my brief description of the Core Build System.

[jonahgraham]

This is a good intro/comparison @ewaterlander

I think one key difference to add to the list at the end is:

• Sharing projects with other IDEs. The Managed Build projects are proprietary to Eclipse CDT and requires Eclipse CDT to build (from UI or command line). CMake projects are an industry standard and many IDEs come with support for CMake. Therefore sharing projects with multiple people and using CMake is easier.

Some notes on the above, proprietary isn't the right word, but it is close. I also though that headless build was documented, but if it is I can't find it . I can thank our friend project embed-cdt which has documented it here

[ruspl-afed]

The Managed Build projects are proprietary to Eclipse CDT and requires Eclipse CDT to build

I would say it looks more like Eclipse CDT "vendor lock". Yes, this is a problem, and many people don't like this.

[ewaterlander]

The Managed Build projects are proprietary to Eclipse CDT and requires Eclipse CDT to build

I would say it looks more like Eclipse CDT "vendor lock". Yes, this is a problem, and many people don't like this.

For us a big advantage is that with Core Build you can use the same (c)make flow for IDE users, command-line users, and nightly regressions. And the real showstopper for MBS was that it is not usable for multi-core systems. Building a GUI to set compiler flags for multiple binaries was not doable, or at least hard to do. People can easily live without makefile generation. The essential parts of the IDE are code navigation and debugging.

[ruspl-afed]

And the real showstopper for MBS was that it is not usable for multi-core systems.

Why so? One can use multiple projects (or multiple configuration that is less usable).
How Core Build helps to work with multi-core systems?

[ewaterlander]

And the real showstopper for MBS was that it is not usable for multi-core systems.

Why so? One can use multiple projects (or multiple configuration that is less usable). How Core Build helps to work with multi-core systems?

It is possible to split into multiple MBS projects. I actually tried that, before I discovered Core Build. But that adds a lot of overhead. I work in a Linux-only environment, where command-line is still king. If I had to ask programmers to split their single Makefile projects, they would not use the IDE.

[ruspl-afed]

If I had to ask programmers to split their single Makefile projects, they would not use the IDE.

Ah, this is to bring the lost back into the fold of the IDE. This is a good argument, I hope it will have an effect.

[ewaterlander]

Ah, this is to bring the lost back into the fold of the IDE. This is a good argument, I hope it will have an effect.

Like Jonah already said, being able to share the project is a key difference. Not only with other IDEs, but also with command-line. We encourage people to use the IDE, but they are free to use command line, or both. If you're able to easily switch between IDE and command-line you can use the best of both worlds.

[jonahgraham]

LGTM - @jld01 if you are happy with the updated language (especially around removal of "old" and use of "legacy") then we are good to go here.

[ruspl-afed]

LGTM

[jld01]

@ewaterlander thanks for the document. I have added some suggestions for consistency and flow. Let me know what you think.

We also need to introduce the HTML file that will be generated at html/core_build_system.html to the Eclipse help system by declaring a topic such as:

<topic label="Core build system" href="html/core_build_system.html" />

in https://github.com/eclipse-cdt/cdt/blob/main/doc/org.eclipse.cdt.doc.user/topics_Getting_Started.xml

[ewaterlander]

@ewaterlander thanks for the document. I have added some suggestions for consistency and flow. Let me know what you think.

I think your suggestions are addressed in the second commit. Did I miss something?

We also need to introduce the HTML file that will be generated at html/core_build_system.html to the Eclipse help system by declaring a topic such

I will add it.

[jld01]

@ewaterlander thanks for the document. I have added some suggestions for consistency and flow. Let me know what you think.

I think your suggestions are addressed in the second commit. Did I miss something?

I don't see where these comments are addressed. At present, the text seems to be in a conversational style. My suggested edits are intended to give the text more of a documentation style in keeping with the other help pages. I would prefer that these changes (or similar) be applied before merging.

[ewaterlander]

I don't see where these comments are addressed. At present, the text seems to be in a conversational style. My suggested edits are intended to give the text more of a documentation style in keeping with the other help pages. I would prefer that these changes (or similar) be applied before merging.

Let's talk about this in the meeting, because I don't see what I missed. And also about the style.

[ewaterlander]

I have included all John's suggestions.
I squashed it into a single commit and rebased on main.

[jld01]

Thanks for the updates, @ewaterlander.

[jonahgraham]

I am very close to finishing #995 - I will rebase this change once I merge #995 into the new location of the file. I think #995 should be merged first to maintain a "nicer" history on this file.

[jonahgraham]

I have rebased and will merge assuming acceptance by CI.

@ewaterlander at the CDT call you mentioned that loading each page was very slow, when you get a chance can you test it again with my recent changes to see if I have resolved the issue. If you still have the problem, can you create a new issue please?

[jonahgraham]

Thanks @ewaterlander for this valuable write-up.

[ewaterlander]

I have rebased and will merge assuming acceptance by CI.

@ewaterlander at the CDT call you mentioned that loading each page was very slow, when you get a chance can you test it again with my recent changes to see if I have resolved the issue. If you still have the problem, can you create a new issue please?

Hi @jonahgraham ,

Thanks for doing the rebase!

I noticed today that Eclipse for committers requires the new glibc, as was announced. Unfortunately at the moment I'm working on machines that don't meet the requirement. Upgrade is in progress, but that may take some time. Perhaps I can get access to an upgraded machine sooner. I noticed the delay also on WSL, so I can test that right now.

[ewaterlander]

I noticed today that Eclipse for committers requires the new glibc, as was announced. Unfortunately at the moment I'm working on machines that don't meet the requirement. Upgrade is in progress, but that may take some time. Perhaps I can get access to an upgraded machine sooner. I noticed the delay also on WSL, so I can test that right now.

On WSL the pages now show without delay. It has improved a lot. Thanks!

I did have a fight with proxy settings. For Eclipse Committers to do it's updates I need to have the proxies defined. But when I run CDT from Eclipse Committers I can't see any help page when proxies are defined. In the launch configuration I can set empty string values to http_proxy and https_proxy, but that doesn't work. They need to be undefined. It is not possible to undefine variables in the Environment tab. So to see the help I have to restart Eclipse Committers without proxies defined.

[jonahgraham]

Thanks for the feedback @ewaterlander

Its been a while since I worked with proxy settings, but it sounds like the proxy is getting involved when destination is localhost (as it is when using help inside the IDE). I don't know how to resolve this, but just to confirm, does it look like:

I noticed today that Eclipse for committers requires the new glibc, as was announced.

You can stick with the older version of Eclipse for committers, it should be just fine.