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 [blib...@gmail.com]
Sent: Thursday, June 09, 2011 3:40 PM
To: Garrett Serack
Cc: coapp-developers@lists.launchpad.net
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.
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : coapp-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
