A pre-translated pure C "bootstrap" release?

[staalmannen]

I am interested in trying to build the edgcpp compiler on Plan9 in my APExp project. At the moment I am working on a pre-translated variant of cfront, but this is of course much more limited than what EDG would be.

A pre-translated (and possibly minimal) pure C release would be great for OSes that do not have a C++ compiler already (like Plan9). This is also the method used by the Portable Object compiler, which I have already ported using a dual bootstrap (old, pre-translated release) and rebuild (current, objc release) build cycle.

An alternative to creating a pre-translated release might be to release a tarball of the last version of the EDG compiler that was written in pure C. This would be similar to how we use the Go 1.4 version (written in C) to bootstrap later versions of Go written in Go.

[daveedvdv-nvidia]

How about instead creating a tool that can be run on this tree to create a secondary tree of C files that can be compiler and linked into cpfe?

I don't know if it is of interest, but the front end has the capability to compile multiple translation units "simultaneously" into one (lowered) IL tree, and that can be fed to the C-generating back end. That way, you can have the front end rendered as a single C file.
See https://edgcpp.org/doc/trans_unit/ .

[wchilders-nvidia]

I think the way to do this is to configure/setup the front end for "cross compilation" for the target (in this case it would seem, Plan9).

Basically a custom defines.h with a target (or the default target) that has everything set appropriately (you can reference what we do for the various targets supported by the linux debug builds).

Then you use a release front end, to build the front end sources (including your modified defines.h + the necessary headers from the Plan9 system) into .c files.

You can then take those self-contained C files to the Plan9 system and you should just be able to feed them into your C compiler and link... producing a new "custom release" EDG front end that can do further C++ -> C translation for that system/architecture.

---

I don't think this is something we want to officially include in some form at the moment because there is a target-specific aspect to this. I'd welcome a guide in dev_annex or something though that demonstrates the capability and steps for others trying to do this.

I did however open #219 because this is a capability that we want to make sure we're maintaining (or rather aren't breaking somehow).

[staalmannen]

This sounds like a perfect compromise. I will convert to C on a Linux host and then move on from there in my porting. Good to know that you will make the C++ to C translation future proof by setting up a CI testing for it.

[DarkArc]

Awesome, thanks for the suggestion and feel free to let us know how it goes and to contribute any notes you want to share with others :)