[SUGGESTION] Organize code in translation units

[fknauf]

trafficstars

Hi,

I attempted to poke around the cppfront compiler, and the moment I added a second translation unit, I ran into linker errors (symbol redefinitions) because there are many functions with external linkage in the existing header files. I felt it'd make my life easier to organize the code into several translation units and add a small build system, so I did it.

At the moment it's mostly a small CMakeLists.txt to build the main executable and translation units for all the external-linkage functions I stumbled over (no automated testing yet), but before I put any more work into it I wanted to sound you out on whether this is something you'd be at all interested in.

You can check out what I have so far under https://github.com/fknauf/cppfront/tree/cmake_refactor . Please let me know if this is at all interesting to you, and if it is what would be needed for a PR.

[JohelEGP]

I've always thought this would be a boon while developing Cppfront.

Building with a single compiler command line is a feature: https://github.com/hsutter/cppfront#how-do-i-build-cppfront. AFAIK, these are not necessarily at odds, although it necessitates some massaging to still allow the feature. But I find it doubtful that Herb would accept a refactor to allow building multiple TUs without committing to a build system.

[fknauf]

I suppose it's always an option to have a single .cpp file that includes all the others. Sqlite does something similar.

I used cmake for this because it's the de-facto standard for pure C++ projects now, and I expect most people who are interested in cppfront will be familiar with it. It's simple enough that porting it to something else would be very little work, though.

[JohelEGP]

This will be easier to implement once the TUs are rewritten in Cpp2. That makes it easy to split the interface and implementation (e.g., see https://github.com/hsutter/cppfront/issues/594#issuecomment-1793627053).