|Re: [cdt-dev] Internal builder status|
One thing is for certain, external builders will always be first class
citizens in CDT. As you mention, for most of us, it's those customers
who fund our work ;).
On Mon, Jul 12, 2010 at 7:21 PM, kesselhaus <kesselhaus@xxxxxxx> wrote:
> 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
> 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?
> cdt-dev mailing list
cdt-dev mailing list
Back to the top