Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Internal builder status


Just my 2 cents, but from my experience, lots of companies do not rely on IDE internal build systems. The would set up an external one, even though it's sometimes harder to handle.

a) the build environment is checked into VCS
b) the build environment does not need an IDE to build (even though, one could use Eclipse headless) c) the configuration can used to build for several platforms, by just including a different sub-makefile d) external tool integration, scripts (sed, awk, perl ..) to generate subsequent outputs, or for patching mot-files or whatever
e) external code generation tools started by makefile
f) code fragments generated at build time (appl. name depending on release/debug, build date/time, versioning)
g) automation of the release cycle

Sure, setting up an initial project is sometimes easier in an IDE, but in the end, the build environment is done externally. E.g. we use an build env based on project local cygwin, make, GNU tools and perl. We generate a VC++ project file for the majority who use VC++ to edit the code. The build process is called by batch files starting make called from 'External Tools' menu. But for me, I can just work in Eclipse/CDT as I like, because I can either call the build process overwriting the make command, or just build from console. And it doesn't matter if we use Tasking TriCore compiler,
or Renesas compiler or Freescale compiler.
Take a look on ePPC and Freescales CodeWarrior, if the compiler is not as good as expected, we can just switch to GreenHills or maybe Tasking compiler without switching IDE/Editor and their included Build System. I'm not sure what GreenHills has as IDE, but CodeWarrior is still not all based on Eclipse, and Tasking just switched for TriCore from CodeWright to Eclipse 1 or 2 years ago.
Renesas has also its own IDE (or did they already switch to Eclipse yet?).

Am 23/06/2010 23:51, schrieb Daniel Jacobowitz:
Hi folks,

Out of the box, CDT uses the external builder for managed make
projects.  We've been looking recently at the internal builder:
whether it works as well, and what advantages it has.

Here's a couple of things we've already noticed that don't work in the
internal builder.  We originally generated this list in Galileo, but I
verified the problems in Helios.

* You can't clean a project with spaces in the name.  The arguments to
rm aren't quoted.  Cleaning appears to succeed (no error), but the
binaries are still there.

* If you build a project then rename a file, the linker is given both
the old .o file and the new one.  It fails with a duplicate symbol

* Cosmetic: The build console doesn't handle spaces gracefully; it
prints out things like "gcc -oHello World.exe src/Hello World.o", but
behind the scenes it runs the right command.

* Cygwin-specific: The internal builder doesn't work "out of the box"
because Cygwin uses symlinks for /usr/bin/gcc.  If you have Cygwin
make in your path and use the external builder, this works fine.

So, before we chase down these bugs (at least, those that matter to
us), are folks using the internal builder in products?  Does it work?

Back to the top