[M3devel] gcc vs. g++ in config files?

[Rodney M. Bates]

On 09/01/2015 11:28 AM, Jay K wrote:
> I suggest we replace "gcc" with "g++".
> In all the config files (and in the bootstrap archives).
> And similar for Sun CC, and Visual C++ use -TP.
>
>
> rationale:
>   It will likely cleanup our LLVM stuff, which currently
>   uses a custom Makefile and drops derived files into the src directory.

There are a couple of problems here.  I initially tried putting compiled
C/C++ code in the build directory.  Since it is target-dependent, it
obviously does not belong in src.  But a bug in the builder just wipes
out the file with a circular symbolic link:

   % import_obj needs work!!
   % import_obj(<name>) puts a symlink in ../BUILD_DIR/<name>.o, pointing to <name.o>,
   % located relative to the src directory.  Later, it links the symlink into the package.
   % If the file is target-dependent, (as these and most .o files are), we want to put them
   % in ../BUILD_DIR, the target build directory, and only target-dependent place we have.
   % But import_obj("../BUILD_DIR/<name>") just replaces it with a circular symlink.
   % When this is fixed, the Makefile will have to be changed to put it in the right place.

The bug shouldn't be hard to fix, it just hasn't gotten to the top of my list.  Then the
.o files can be moved to the build directory.

But that's still using make to build the .o files.  The other problem is the cm3 build system.
It's really quite sophisticated about dependencies within Modula3 code, but things like
'c_source' don't, as far as I can see, do any dependency analysis at all.  They work fine
for the odd .c and .h files here and there in the cm3 tree.

But the bindings to llvm (the parts we must write in C & C++) bring in large #include closures from
the llvm source tree and then link in several compiled llvm libraries.  I don't think cm3's
build system is at all up to this.  So I used make for that.

Actually, as far as I can find, llvm has not provided any dependency information about what
libraries will be needed, in what order (which, BTW, undergoes reversal of certain segments).
So far, it has been a very dicey and frustrating game of wild guesses and experiments.  I am
sure the lists I have come up with must have some undetected unnecessary things.  I haven't even
figured out a way to find out what library a link name declaration is in.


>   It will ease/allow using C++ exception handling in the C backend.
>   I've been using g++ for months/years on Darwin.
> counter-rationale:
>   Not all C code is valid C++, and sometimes the meanings are different.
>   I converted the coverage code only recently.
>
>
>   - Jay
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org