[M3devel] removing occurences of target name output?

[Jay K]

Ok here is are some choices/proposal.


 - Do nothing -- or at least commit nothing.
 I have to do something -- my goal is to show that various
 targets are the same, with the C backend and possibly cm3cg.


 
 - add switch cm3 -trim-paths  confusing name?
   add swich cm3 -omit-target confusing name?

   Whatever is this switch, add it to cm3g also. The same name.
   Add switch to scripts/python/pylib.py -cm3:xxx
  The xxx part is passed to cm3.
   e.g. do-pk.py -cm3:-omit-target

   
 The behavior of the switch:
  in cm3, it is passed to the backend somehow. 
     Either as a flag to the quake function, or
     by setting a quake global; somehow shield
     the LLVM backend. 

     
  Bring back the function m3front/Host.Tail.
  This historically finds the last forward slash or
  backward slash or space in a string, and returns everything
  after it.
  Modify it to check this new flag, and if the new flag isn't set,
  return the path unchanged.
  
  
  In m3cc, dbxout.c and dwarf2out.c, there is one place
  each that outputs the current working directory.
  If this switch is set, don't do that.
  
  
  In m3front/M3Header.m3 and Scanner.m3 where it makes up those
  strings with "=>" in them, pass the left hand side through
  Host.Tail.

  
  In m3front Scanner.Here, if the flag is set, return
  the value of LocalHere instead. I think. I think that is
  required to remove more occurences. I can double check.
  
  
  In m3back/M3C.c there is one place that outputs the
  target in a comment. Either just remove that unconditionally, or
  remove it subject to this switch.
  
  
  That last point, and the actual goal, is why "trim-path"
  isn't an accurate name. It does so happen that "paths"
  are usually where target occurs in the output semi-unnecessarily.
  
  
  It could very well be that we do want this behavior in cm3cg long term,
  such that whoever makes a distribution, at whatever path, gets the same result.

  
 I do not want to go the route of omitting debug info entirely, which also
fixes this.

  
  It would be nice if something could be specified symbolically.
  Such as wherever the expanded form of $CM3_TARGET occurs in a path
  in the output, change it back to $CM3_TARGET. Like how the
  .m3ship files are optionally generated and like I've seen
  in other compilers -- there is a goal in general to have
  some sort of ull path, but not require everyone to build
  with the same paths, and still get identical outputs.


 This somewhat requires debugger cooperation, depending on their
source search algorithm.
 
  
  When cm3 parses the command line, store this boolean in... Target.OmitPathss?
  Target.TrimTargetString? M3Middle.LessTargetDependentOutput? 
  M3Middle.TrimTarget?
  
  
  Obviously this is a minor tactic -- sizeof(integer) will for now
  continue to be endemic in the IR and the backend output.

  
  The actual goal here is not to make one C output, but a small number.
  I intend soon to introduce the following targets, something like:
    POSIX32LE  
    POSIX32BE  
    POSIX64LE  
    POSIX64BE  
    WIN32LE 
    WIN64LE 


 C or C++ backend is implied, by lack of processor. 
     

 Or maybe:
    C32EL_POSIX
    C64EL_POSIX
    C32BE_POSIX
    C64BE_POSIX
    C32EL_WIN32
    C64EL_WIN32


These 6 targets shall be the basis of a "universal" download/bootstrap, easier
for people to get started with.  
 Eventually the output will use C++ exception handling so I'm leary
 of backing the name "C" in too much.
 
 But I'm getting ahead of myself.
 
 This "trim target" is an important validation step for that.

 
 Ok in principle?
 Ok in detail?
 Or just do nothing?


   - Jay