The makefile project of cygwin GCC configures the automatic discovery of symbols and paths in eclipse CDT.

First, the mingw GCC tool set project does not have this problem:

CDT can find the mingw tool set installed, activate the toolchain of mingw GCC, and make it optional when creating a C/C ++ project, in this way, you can use the CDT generator to generate makefile. There is no problem with automatic discovery of symbols and paths, and there is no problem with the source index.

Automatic Discovery of symbols and paths: it refers to the differences in the compiling environment in the C/C ++ program, which will be searched under several default paths. H files and library files, usually the header files and library files of the standard/RT library are put there, so # include <stdio. h> you can find and include the specified header file without specifying the standard header file stdio. h path. In addition, the compiler will generate built-in macro symbols. For example, C ++ compilers usually generate _ cplusplus macros. the built-in macro definition has a great relationship with the specific compiler. For example, cygwin GCC has _ cygwin _, _ gnuc _, and other macros that identify the compiling environment.

The cygwin GCC problem occurs here. CDT cannot find cygwin tool set installation, which is related to the version: Early cygwin can also be automatically discovered by CDT, and activate the toolchain option of cygwin GCC. However, the cygwin setup 2.680 I used cannot be automatically discovered by CDT (eclipse 3.4.1, CDT 5.0.1. The most obvious change to the installation settings of cygwin is that it changes the registry key that identifies cygwin installation, and CDT relies on the registry to find the installation of cygwin, mingw, and other tool sets. From this nabble.com
The post above shows some clues.

I also don't want to engage in the registry, so I had to do the CDT project of the makefile type. Some makefiles I previously wrote can be used in my hand. I can use autotools when the project is bigger.

Which knows how to enable makefile project to use the symbol index of CDT.

The reason is the problem above. CDT does not know the existence of cygwin, so it is like # include <stdio. h> this sentence will be wrong when a symbolic index is created (the CDT will show a wavy slide and note: unresolved regression sion), because the CDT cannot find stdio. h. Check the results of automatic discovery of symbols and paths during the generation process. In Project Properties → C/C ++ General → paths and symbols, you will understand-No Default include path or built-in macros are found (check show built-in values ).

Of course, the symbolic index of CDT has nothing to do with the compilation process. cygwin GCC normally compiles and generates programs, but the source code browsing function of CDT is weakened during editing, the powerful source code symbol index IDE is now only a highlighted syntax display tool.

After several twists and turns, I discovered how to configure the makefile project to use the CDT symbol and path for automatic discovery. The steps are as follows:

1. In Project Properties → C/C ++ build → discovery options, set the discovery profiles scope to configuration-wide (if not, create this ), note: Check the automate discovery of paths and symbols in the configuration below. This affects the automatic discovery of include paths and macro symbols in C/C ++ General → paths and symbols in the project properties.

2. Select the discovery profile as the GCC per project release info profile, which is parallel to many profiles with the prefix of managed build system.

   The profile of managed build system corresponds to the path/Symbol automatic discovery settings used by the built-in make Builder (called CDT internal builder) of CDT. The external make tool provided by cygwin is called GNU make builder) find clues in project properties → C/C ++ build → tool chain editor.

3. Note: If you set the compiler invocation command to GCC or G ++ in discovery options, an error may occur. This is the default compilation command (black line…) that the CDT will help you fill in ......), The reason is that GCC and G ++ in cygwin may be symbolic links. Only programs constructed using cygwin systems/libraries will realize that this is a symbolic link. Otherwise, Windows programs will, including CDT, it is only a text file (use a hexadecimal editor to check the content of the symbolic link file created by ln of cygwin ), in this case, an error occurs when you run a text file. The solution is to find
   The actual target compiler program to which the GCC/g ++ symbolic link points, usually gcc-4.exe0000g00000000-4.exe (4 is the version number, depending on the situation ), as long as the gcc-4/g ++-4 is set to compile the command line.

4. After the final re-Compilation of your project, the CDT will use the GCC set in discovery options to do the default include path and built-in macro development (the method is to do-e preprocessing on an empty source file ). Now you can look at the include path and macro symbol automatically discovered by CDT in project properties → C/C ++ General → paths and symbols. Let's take a look at the # include <stdio. h> standard header file in the source code. Now we have automatically discovered the location of these standard header files. Finally, you can press Ctrl to enjoy the powerful source code symbol of the CDT.
   VC intelliisense, VC + visual assist X, source insight, and other accurate source code symbol indexes, not to mention that CDT is open source.