Skip to main content

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

FWIW, I would like to support kesselhaus's comments. In my organization the internal builder is of no use. We use the external builder for the exact reasons he states.

On Mon, Jul 12, 2010 at 4:27 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
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:
> 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?
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
cdt-dev mailing list

Back to the top