1

My organization has a large C/C++ codebase. We build many binaries from subsets of this codebase, both production and test binaries. There are many build variants. The same C/C++ source files are compiled with different -I and -D compiler flags in different binaries. Example: Binary "test1" might compile "file.c" with one set of -I and -D flags, while "test2" compiles the same file with other flags.

How do you set up an Eclipse CDT project for such a codebase?

We have tried two approaches, which both were fairly unsuccessful:

  1. Create one project for each binary, with its -I and -D flags.

  2. Create one project with the union of all -I and -D from all binaries.

  • What are your requirements for the project setup? Are you looking to use CDT's Managed Build to build the project, or do you just want the Build function in Eclipse to call out to an existing build script like `make`? Do you want to be able to open "file.c" in different modes (e.g. "file.c as built for test1" vs. "file.c as built for test2") and see different things (e.g. different sections of the marked as inactive preprocessor branches)? – HighCommander4 Oct 30 '19 at 02:32
  • We are building the project from the command line with the Build function. (That is, we are not using Managed Build.) Our main use case is code browsing. It is probably OK that Eclipse finds several .h files with the same names, or several definitions in different .c files, and that the user can choose which file to open when he tries to open a definition. But ideally the defines should be correct, that is the proper #ifdef should be marked as active. – Magnus Andersson Oct 31 '19 at 09:56

1 Answers1

0

Based on the requirements you describe, I think the best fit would be using CDT's Build Output Parser. I wrote an explanation of how to use it in this previous answer.

Basically, the Build Output Parser invokes your build script, and parses its output to deduce the correct settings (-I and -D flags) for each source file.

A note on parsing a file in multiple configurations: CDT supports this for header files, but not for non-header source files (such as .c files). So, if you have a header file header.h which has some #ifdefs and is included by two different source files file1.c and file2.c with different macros defined at the point of inclusion -- then you can open header.h from the #include in file1.c and get a correct view of "header.h as included from file1.c", with the right parts greyed out and all. However, if file1.c itself is compiled in two different modes, I suspect the Build Output Parser will just pick one of them and you're stuck viewing it in that mode.

HighCommander4
  • 50,428
  • 24
  • 122
  • 194
  • Thanks for the answer! Unfortunately we use a build system that do not log the raw compiler commands. Are there any other standard ways to find the -I and -D flags? We could implement a query (say `make query ...`) in our build system to log all -I and -D flags in the build. – Magnus Andersson Nov 04 '19 at 21:17
  • @MagnusAndersson That's exactly it: your build script doesn't need to log the raw compiler commands *by default*, it just needs an option to do so. Then you can just change the "Build command" in Project Properties --> C/C++ Build --> Builder Settings" to include the option. – HighCommander4 Nov 05 '19 at 07:23
  • Ok! I will try out the Build Output Parser. Thanks again! – Magnus Andersson Nov 05 '19 at 14:26