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
>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
