coapp-developers team mailing list archive

[Lee Fisher <blibbet@xxxxxxxxx>]

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.