26

How can I get Eclipse to build many binaries at a time within one project (without writing a Makefile by hand)?

I have a CGI project that results in multiple .cgi programs to be run by the web server, plus several libraries used by them. The hand-made Makefile used to build it slowly becomes unmaintainable. We use Eclipse's "Internal Build" to build all other projects and we'd prefer to use it here too, but for the good of me, I can't find how to get Eclipse to build multiple small programs as result instead of linking everything into one binary.

SF.
  • 13,549
  • 14
  • 71
  • 107
  • 1
    You should consider asking a separate question about how to make your Makefile more maintainable, in case this one is a dead end – Zac Thompson Jun 24 '10 at 05:54
  • I second the thought expressed by Zac. Why is your Makefile unmaintainable? Many, many large and complicated software projects use makefiles quite successfully on rapidly changing codebases. – Joel Hoff Jun 27 '10 at 23:52
  • @JoelHoff: This is to be compiled both from Windows and Linux to ARM. The Windows machines have Cygwin, msys, and several crosscompilers for different projects. The utter mess of `/` vs '\`, `$PATH` vs `%PATH%` and generally getting the right toolset to launch when compiling (e.g. encourage g++ to use cross-tools and libraries from its own folder instead of searching /bin for cc1 for no good reason) gets increasingly burdensome. It's all nice and dandy if you have projects you cross-compile all to one platform with one tool set. If you support 4 different embedded architectures... – SF. Jun 03 '19 at 06:55
  • that are additionally quite similar, enough to use similar crosstools and compile using any but dissimilar enough that wrong toolset will make a dysfunctional binary, and having to juggle them through rewriting $PATH in batch or bash scripts, that gets very unmaintainable quick. Eclipse's ability to override the environment variables on per-project basis is very helpful there. Luckily we've moved to cmake+ninja and it handles the quirks only with minimum of fuss. – SF. Jun 03 '19 at 06:59

3 Answers3

31

Solution for this described there: http://tinyguides.blogspot.ru/2013/04/multiple-binaries-in-single-eclipse-cdt.html. There is an excerpt:

  1. Create a managed project (File > New C++ Project > Executable)
  2. Add the source code containing multiple main() functions
  3. Go to Project > Properties > C/C++ General > Path & Symbols > Manage Configurations
  4. Make a build configuration for each executable and name it appropriately (you can clone existing configurations like Debug and Release).
  5. From the project explorer, right click on each source file that contains a main() function > Resource Configurations > Exclude from Build and exclude all build configurations except the one that builds the executable with this main() function
  6. All other code is included in all build configurations by default. You may need to change this depending on your application.
  7. You can now build an executable for each main function by going to Project > Build Configurations > Set Active , Project > Build Project
Johan Engblom
  • 215
  • 1
  • 12
hovercraft
  • 326
  • 3
  • 3
  • 3
    or build them all at once through `Project > Build Configurations > Build All` – SF. Nov 09 '14 at 08:01
  • 1
    @SF. Build all will only build the active configuration. To build them all using a single `Ctrl+B`, go to "Project > Properties > C/C++ General > Path & Symbols > References" and mark in one of the configuration the others. – Liran Funaro Dec 26 '18 at 14:18
4

Using Eclipse as your build system for production code seems like a bad idea in general. I think it's a great IDE and have used it extensively for both Java and C++ projects, but for a build system I firmly believe that Ant, make, and other dedicated build utilities are the way to go.

There are several reasons for this:

  • Dedicated build utilities offer the very flexibility you are looking for in generating multiple executable targets.

  • Ant and make support most conceivable arbitrary build process chains (though not quite all).

  • A dedicated build utility is likely to offer greater stability and backward-compatibility for build description file formats than an IDE tool like Eclipse. Also, I'm pretty sure that Eclipse's internal build feature is dependent on the ".project" file description, and the latter's format is probably not as stable as the build description format for either Ant or make.

  • General-purpose, basic build utilities are usually command-line-based, which makes it easy to integrate them with more sophisticated, higher-level build utilities for automated build management like Pulse, CruiseControl, etc.

The need that is motivating your question is telling you that it's time to make the switch to a better build tool.

Joel Hoff
  • 1,993
  • 20
  • 22
  • 1
    This is more of a comment than it is an answer. In general, I agree with your observation about why using Eclipse as your product build tool is not a good idea. However there are plenty of valid reasons why you want to be able to build multiple executable files from a single Eclipse project. – Jay Elston Feb 21 '19 at 19:49
2

There is a way to use s to create one binary (or shared library, in my case) from each build config. Using the answer above, this means to manually exclude all but the effective main file from each build config.

I just used the above answers to ease up working on my project that creates 14 shared libraries through 14 build configs. However, configuring the indivdual "exclude from build" setting was quite cumbersome, so I switched to using the following code relying on a as my complete main file:

/*
 *main.cpp
 */
/* Within
 *  Project | Properties | C/C++-Build | Settings
 *  | GCC C++ Compiler | Preprocessor
 * set the following defined Symbol:
 *  _FILENAME=${ConfigName}
 */
#define __QUOT2__(x) #x
#define __QUOT1__(x) __QUOT2__(x)
#include __QUOT1__(_FILENAME.cpp)
#undef __QUOT1__
#undef __QUOT2__
/* The above include directive will include the file ${CfgName}.cpp,
 * wherein ${CfgName} is the name of the build configuration currently
 * active in the project.
 *
 * When right clicking in
 *  Project Tree | (Project)
 * and selecting
 *  Build Configuration | Build all
 * this file will include the corresponding .cpp file  named after the
 * build config and thereby effectively take that file as a main file.
 *
 * Remember to exclude ALL ${CfgName}.cpp files from ALL build configurations.
 */

Note that it does nothing else then include another .cpp file which's name is deduced from the and a symbol that is set in the compiler options. The symbol is ${CfgName} and will be replaced by the current config name by eclipse automatically.

One does not need to configure, which file is included in which build config. Just exclude all ${CfgName}.cpp files in every build and include main.cpp in every build.

PS: the answer from hovercraft gave me the idea to have a main file that does not contain code on its own. If one includes shared code from the different effective main files ${CfgName}.cpp, working on their code may become infeasible because header files in main.cpp will not be visible in them. I did this until yesterday, but maintaining the code with broken index etc. was a big pain.

PPS: this procedure currently breaks the automatic rebuild of the main file if only the included .cpp file was changed. It seems that eclipse does not recognize the changes in ${CfgName}.cpp (which is excluded from build). So a manual rebuild is required after every change. This is currently bugging me ;)

Sven
  • 21
  • 6