[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Internal builder status
|
Hi,
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.
Reasons:
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
error.
* 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?
