| Feature Request: An option for compiler discovery in managed make [message #143158] |
Wed, 13 April 2005 04:53 |
 Vince Mounts
Messages: 1
Registered: July 2009 |
Junior Member |
|
|
I have a suggestion to make "compiler discovery" more useful in the CDT.
These suggestions focus on the use of GCC as the compiler. My appologies
if there is some other way to what I am describing. If there is, I could
not figure it out.
Also, this is a bit long for such a simple request ;-) but I wanted to
make sure it was understood what "problem" I was hoping to solve with my
request.
General background:
When using the gcc compiler to compile programs on windows there are
currently 3(not 2) options.
The first is the use of the gcc supplied by cygwin (www.cygwin.com).
Out the box use it uses a unix emulation layer (cygwin1.dll) when it
compiles.
The next 2 are nearly equivalent. They are using the gcc supplied by the
mingw group (www.mingw.org) and using the gcc supplied by cygwin(same
one as above) but passing a switch to it (-mno-cygwin). I say nearly
equivalent because , much like a linux distibution, these 2 groups are
often on different release schedules (cygwin usually lagging a little
behind mingw). So, the compiler and binutil versions can be a little
different. Other than that the output is exactly the same. That is, a
binary compiled to use the Windows suppiled c-runtime (msvcrt.dll)
(cygwin just redistributes the headers the mingw group produces but uses
their build of the compiler... a sort of cross-compiler)
Re Managed Make:
Some users prefer to only download the cygwin supplied tools and use
them with the approriate flag (mno-cygwin) instead of having 2 copies of
gcc. While, under "Managed Make", it is possible to pass this flag
through "Project Properties| C++ Build| Tool Settings| GCC C++ Compiler|
Miscellaneous| Other Flags" (whew... what a mouthful), there is no way
to specify this flag during the include discovery phase (which is
completely hidden in the managed make).
Even when using separate compilers for each situation, it is neccessary
to exit eclipse , change your path variable and then relaunch eclipse.
This is less than ideal as the use case I've included below demonstrates.
Even with this path changing technique the CDT doesn't seem to update
the files under "includes" in the project explorer at any reliable time.
(e.g. right clicking the project and clicking refresh doesn't seem to do
anything... I think maybe it does it after a build though?)
Re Standard Make:
While it is possible to specify the approprite flag for include
discovery in the standard make, there is no easy way to switch between
different environments. The discovery flags are for the entire project
only. Also , as above, the discovered directories don't seem to refresh
themselves once the option is changed (even when clicking "refresh" from
the project right click menu).
Ok, now a real use case for why this is even an issue. This is only for
the managed make project. For the standard make, it would really be
enough to just have the include discovery refresh itself when the
project make properties are changed. But, it seems a shame to force the
user to go to a standard make for the lack of one field in the managed make.
Use case:
One of the reasons the cygwin compiler is used is to bring programs
orinally written for Unix to windows. Since cygwin provides a Unix
emulation layer for windows a program can be compiled with cygwin with
very few changes to the source code. Often times , however, this only a
temporary solution. The emulation doesn't come for free. There is a
definite speed penalty for many applications. Therefore, once a program
is running using the cygwin emulation layer it is often desirable to
modify the source code further to make it run against the native windows
runtimes (mingw aka msvcrt.dll).
The inverse is also true. One can migrate from a windows based console
program to a unix based one with cygwin as an intermediary.
During this migration period it would be very useful if the developer
could easily switch between compiling against cygwin or mingw without
reloading the eclipse workbench. And that the CDT parser and code
verifier were using and showing the correct include files.
E.g. make a change to some file handling code. Right click on project,
then properties. Go to C++ Build and change "Configuration" to cygwin.
When exiting the dialog, the includes refresh to the current
environment. Click rebuild project and the cygwin version is built.
Now go back to C++ Build and change to mingw (which simply has added the
-mno-cygwin switch to the commands and the _new_ discovery option
suggested below). When exiting the dialog the includes refresh to the
current environment. Click rebuild project and the mingw version is built.
I should note that right now the the proper executable is built if you
set the GCC other flags to -mno-cygwin. It is simply a matter of the
wrong include files showing up in the IDE.
To recreate:
1)Make sure the cygwin package is first in your path when launching
eclipse from a windows console.
2)Create a new managed make C++ project.
3)Write a simple hello world program like in the help file.
4)Save and build the program
5)If you have a dependency walker type program run it on the created
executable and you will see that it depends on cygwin1.dll
6)Under "Managed Make", it is possible to pass this flag through
"Project Properties| C++ Build| Tool Settings| GCC C++ Compiler|
Miscellaneous| Other Flags" add -mno-cygwin as flag.
7)Notice the includes listed in the project explorer are the same as before.
8)save rebuild the project
9)If you have a dependency walker type program run it on the created
executable and you will see that it _does not_ depend on cygwin1.dll,
but instead only msvcrt.dll
10) Notice that no matter what you do the includes listed in the project
explorer will never change to the correct version. This is becasue you
need to pass -mno-cygwin as an option when the discovery phase is run.
Possible solutions:
For managed make: Add a per "Build Configuration" option under "Project
Properties| C++ Build| Tool Settings". Perhaps, instead of a full
command line like in standard make, this could just be an "Additional
Discovery Options" field under the "GCC C++ Compiler" section.
For both managed and standard: When the properites dialog is closed ,
and when the user right clicks on the the project in the project
explorer and clicks refresh, the include discovery should be redone.
I am not really much of a Java programmer, but if someone pointed me in
the right direction, for what files to look at, and there was a
reasonably good chance it would be included if I made the changes(it is
bound to be painful for me with my very limited Java experience so I
don't want to waste too much time if it won't be accepted anway), I
would be willing to look at this.
Take care,
Vince Mounts
|
|
|
Powered by
FUDForum. Page generated in 0.03621 seconds
] 
Search
Help
Register
Login
Home
