coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

I don't have a spec for that... the goal here is to consume information gathered
from tracing builds with gcc (cygwin or mingw) and produce compiler independent 
build scripts (which can be transformed into VCXProj files, or others (like 
cmake))

I've got to account for all the gcc switches (even if I discard them)--simply 
because I don't want to accidentally discard something that I wasn't aware of.  
If I'm not at least aware of 100% of the switches, then stuff is gonna break 
elsewhere... 

Really, the two big tasks:

1. Categorize each switch into one of the following groups:

    Invalid switches -- things that we should never ever see in a successful 
    compile (ie, --help)
    
    Ignored switches-- things that we can safely drop, because when we generate 
    the new project we will supply those if necessary (most optimization 
    switches, switches that dictate where files are placed, generation of 
    mapfiles, PCH stuf, etc...)
    
    Control Switches -- things that just set a feature on or off
    
    Parameterized Control Switches -- things that set a value of a particular
    feature (in VC, stuff like /GS[-] , /fp:[type], etc)
    
    Fuzzy Control Switches -- Ones that take a parameter that may or may not 
    be the next argument on the command line (in VC, things like /D can be 
    expressed like /DMACRO=VALUE or /D MACRO=VALUE)... not sure if any in 
    gcc do that...
        
    Greedy Control Switches -- ones that consume the rest of the command line
    (like /LINK in VC)
    
    Special Case Switches -- ones that we know we want to handle, but are going
    to ignore in the short run (essentially until we really need to look at 
    them--depending on their use in the real world.) 
    
    
2. Write the C# class that loops thru and parses out the command line and 
    records the appropriate settings and files. (this is easy, but boring)
    
    
It's not so much knowing what they do, it's just a matter of sitting down and
using some judgement to categorize them.  And given that there are large 
collections of switches which we can knowingly dump into the ignored category
it's worth doing the work now to make that happen.
    
    
________________________________________
From: Lee Fisher [blibbet@xxxxxxxxx]
Sent: Thursday, June 09, 2011 3:40 PM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Volunteer to help with GCC command line analysis...

Where is the CoApp spec that discusses what kind of mappings you're
talking about in this email? I'm unclear of the goals.

There's some data here that might help:
http://sourceforge.net/apps/mediawiki/predef/index.php?title=Main_Page
and to a lesser degree:
http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues#Compiler_Options_and_Flags

I seem to recall the MSC team having some spreadsheets that mapped
things between MSC, Borland, Intel or IBM (?), and GCC (probably 2.x).
So they could track memory models and calling convention compat, I
think. You might ask if the current VC PM if they still have this data,
and can use a subset of it for this public project.

And wouldn't there be something related in MinGW's use of MSCRT with
GCC, that'd help for this mapping?

Why are you looking at 100% of the GCC switches? Why not use the subset
that CMake or Autotools use, that's got to reduce the complexity for
initial release, right? IMO, if Autotools or CMake don't generate that
switch, then perhaps it's not too interesting to deal with for initial
CoApp release.

If you can't look at the Autotools or CMake source, you could probably
run CMake against a test app, then look at it's generated MSC and GCC
build scripts. And those'll probably become your initial tests for this
feature, anyway.

PS: The Eclipse CDT MSVC toolchain project would also like to have this
data, I expect. :-) That'd solve half their problem, for the other,
they'll have to deal with the Windbg/NTSD debugger API and mapping that
to the Eclipse debugger interface (but at least there's a good API now).
http://wiki.eclipse.org/CDT/designs/msvc

On 6/9/11 8:44 AM, Garrett Serack wrote:
> I just took a look at the GCC command line list. (http://gcc.gnu.org/onlinedocs/gcc/Option-Index.html)
>
> There are 1,993 different command lines... And while yes, a heck of a lot are warning flags, they still have to all categorized so that I can parse out the command line correctly. And then we have to reconcile options against the ones that VC has, and create more fields for the rest.
>
> Hmm. This list (http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary) may help a lot when it comes to categorizing options we don't have to worry about.
>
> Still, there is one hell of a lot of options  that have to be handled.
>
> Is there anyone who could help me with this? It's a rather hefty task, and I'm never gonna get this done anytime soon if I don't get some serious help on this.