Skip to main content

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

We've been using our own project builders for several years now, so I haven't actually kept up with standard/managed make in CDT.  I was poking around generic CDT projects yesterday when doing some Qt research, and wound up being a little confused.

A few years ago there was standard make, which simply called make on an existing makefile, and managed make, which created and maintained makefiles.  Managed make introduced the build configuration concept, which I believe was then added to standard make as well.

I see now there's this concept of managed make with internal or external builder.  Is the former just managed make, and the latter standard make, or is there is still an actual standard make builder?  If so, what's the difference between the two?

How is the indexer hooked up in these projects?  I created a Qt project and the indexer just seemed to work, but I wasn't sure how.  :)  Is it getting the macros and include paths from the makefile?  I didn't see any place to specify the makefile location, so I was a bit puzzled as to how it was working.

Thanks,
Warren



>-----Original Message-----
>From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>On Behalf Of ext Doug Schaefer
>Sent: Monday, July 12, 2010 6:28 PM
>To: CDT General developers list.
>Subject: 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:
>> 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


Back to the top