[M3devel] full source paths in debug info, environment variable to contain switches?

[Jay K]

I raised this matter years ago and people disagreed.

Debug info, and probably compiler diagnostics, should have full source paths.

Ease of use of compiler diagnostics varies, better and worse, with full paths.

Debuggers similar.

gcc and clang on Darwin use full paths.
Observe:

jair:~ jay$ cat 1.c
int main()
{
}
jair:~ jay$ rm a.out 1.o
jair:~ jay$ /Users/jay/gcc-6.1.0-min/bin/gcc -g -c 1.c
jair:~ jay$ dwarfdump 1.o | fgrep 1.c
             AT_name( "1.c" )
                 AT_decl_file( "/Users/jay/1.c" )
jair:~ jay$ rm a.out 1.o
rm: a.out: No such file or directory
jair:~ jay$ clang -c -g 1.c
jair:~ jay$ dwarfdump 1.o | fgrep 1.c
             AT_name( "1.c" )
                 AT_decl_file( "/Users/jay/1.c" )


Now, for my immediate task at hand, I actually don't want this, at least for instantiated generic modules/interfaces.

I propose cm3 should have some command line switches to control this behavior.
The default should be full paths in debug info.


I further propose that some environment variables be implemented, which shall contain cm3 switches.
There is some precedent for this in the world.

In the Microsoft C/C++ toolset:
INCLUDES is include paths
LIB is library paths
CL, _CL_, LINK, and _LINK_ environment variables all contribute to compiler/linker command line (I think prepending and appending).


I don't propose that many or generally that short of names, but maybe

CM3_OPTIONS
or CM3_ENV
?
I don't want to use just CM3, because people might want that to contain the path to cm3 (without switches(


Probably some command line option should quash this too, like cm3 -noenv
Which maybe should also work, if it is in CM3_ENV, means to ignore the rest
?

This is at once crude and powerfuli and elegant and hacky and efficient and inefficient.
It is good because it is easy to use and will usually do what people want.
It is bad because it is not scoped -- it travels through entire process trees.
It is inefficient because it travels into processes that don't use it.


For my current work, I went to shorten paths such that the target doesn't occur in them, so I can show that various targets generate identical C code, so I can fold them down to fewer targets. The paths to generic instantiations messes this up, at least.


 - Jay