views:

149

answers:

2

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.

+1  A: 

Could you have multiple projects in one workspace, each building its own executable?

Arkadiy
Yes, but having 60+ projects in one workspace (most of them differing with one file from the rest) is not my idea of "maintainable".
SF.
Do you build 60+ executables? The "differing with one file" can probably be addressed with some refactoring/libraries, but 60 executables... That's tough.
Arkadiy
From what I can tell, you can only configure one "artifact" in the project settings. So if you don't want to use a makefile, you only get one binary per project. Some build systems adhere to the "one project, one artifact" approach; the expectation is that dependent binaries will be built in separate projects.
Zac Thompson
@Arkadiy: It's many, many CGI scripts, each a function of a web API. They are currently all separate files in one directory, with common pieces linked from a separate location (some statically some dynamically). Not much refactoring to be done here.
SF.
Are you sure you don't want to combine them? One large executable loaded 60 times may not be wasting more memory or disk access than 60 smaller ones. In fact, you may be gaining some, as any code that's repeated in smaller executables is loaded 60 times. It all depends on the optimization that the system provides for loading executables into memory.
Arkadiy
I have serious doubts. No more than two, 90% of the time one person will access the page at a time. Some of the binaries are nearly never launched (access to obscure configuration). Others are launched once a second or more (serving state change live). Never all of them are running simultaneously - only 1-2 instances at a time. Keeping them lightweight is essential. Besides, most of shared functionality is offloaded to a common .so, which is loaded once, one instance for use of all.
SF.
What is your definition of "lightweight"? Load time? Memory used by code?
Arkadiy
1. Memory footprint 2. CPU usage. 3. execution time(total, load+run) This is an embedded system. RAM is scarce, CPU time is needed elsewhere, the user can't wait ages for reply (and some 'scripts' must fit themselves in 1s because that's how often they are called periodically)
SF.
+1  A: 

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