[RFC] Use a submodule to avoid duplicating source code

[Geod24]

@WalterBright : Since any change to the backend means painful duplication for you, I propose that we refer to DMD directly and remove the duplication completely.
By doing so, you can incrementally advance the submodules, resulting in less effort when adapting code, but we can also add a CI job in DMD which tests that DMC isn't broken, like Buildkite currently test that we don't break other people's projects.

Unfortunately I am not able to test the changes because there's no instructions on how to build on POSIX.
I took a look at https://github.com/DigitalMars/Compiler/blob/master/dm/src/dmc/posix.mak but it's still referencing the .c source files.

If you would like to test, you can do this:

$ git clone https://github.com/Geod24/Compiler.git mathias-dmc
$ cd mathias-dmc/
$ git submodule update --init

The compile as you are used to (I suspect cd dm/src/dmc && make ?).

[Geod24]

For reference, those two files are exactly the same, hence why I started there:

sha512sum dm/src/dmc/backconfig.d dm/src/dmd/src/dmd/backend/backconfig.d
c3625353efa58b27e3945783e1f2b0a09356b5badf66fbe09a81c2be2c3cae7e7641e665206f9aa17f13ca825abacc611bf6a7f16794e2a8beb201e3085e3196  dm/src/dmc/backconfig.d
c3625353efa58b27e3945783e1f2b0a09356b5badf66fbe09a81c2be2c3cae7e7641e665206f9aa17f13ca825abacc611bf6a7f16794e2a8beb201e3085e3196  dm/src/dmd/src/dmd/backend/backconfig.d

[WalterBright]

Unfortuately, dmc has not been ported to Linux.

[Geod24]

Right. Does it work on win64 or only win32 ? I'll see if I can put a Windows Github CI in place.

[WalterBright]

Only Win32

[Geod24]

@WalterBright : How do you compile DMC yourself ? The instructions in the README seem rather out of date.
One example is that symtab.d seems to be missing from this repository despite being unconditionally imported by global.d.

[WalterBright]

Oops, I had omitted symtab.d. It's there now.

I compile using make scppn

[WalterBright]

@Geod24 there's another problem, sometimes my efforts at syncing dmd with dmc fall behind, at the moment dmc is a bit behind. I need to do some work there.

[Geod24]

@WalterBright : I've made good progress, and I'm now blocked by the usage of extern(Pascal) here:

Compiler/dm/src/dmc/dgetcmd.d

Line 47 in e8557fa

mixin("extern (Pascal) int response_expand(int*, char***);"); // from dmc dos.h

[WalterBright]

Oops. Not sure what to do about that.

[Geod24]

@WalterBright : Actually I can just use an older compiler. melf.d is also missing.

[WalterBright]

melf.d

Added. Obviously, I haven't built dmc from the git repository. Shame on me.

[WalterBright]

I'm not changing dmc so it requires code from dmd to be built. It's much easier to deal with as a separate project. I've also tried to keep the dmd backend from getting entangled with the dmd front end, although a couple imports have crept in.

P.S. One of the reasons I've resisted "packagizing" the dmd front end is because the packages all wind up importing each other rendering it more a nuisance than an aid. Packages (and the backend is a package) should really strive to not import anything uplevel or sideways.

[Geod24]

I'm not changing dmc so it requires code from dmd to be built. It's much easier to deal with as a separate project. I've also tried to keep the dmd backend from getting entangled with the dmd front end, although a couple imports have crept in.

I fully agree with you here. I really think the backend should be a separate project, that could live as a submodule for both DMD and DMC. But I'm not sure you'd agree with this.

[12345swordy]

I concur with @Geod24 here, having the backend be a submodule would be much easier as it creates separation of concerns.