Skip to main content

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

The internal builder is meant for environments that don't always have
make available. It is the default builder for the MinGW toolchain
integration so you could theoretically support building with MinGW on
Windows without having MSYS or relying on MinGW's cut down version of
Make. However for Wascana, I ship MSYS anyway.

I know Chris R was a big supporter of it. I'd wait to hear from him
first. But despite being one of the leading visionaries for it, I'm
actually leaning more to managing builds externally using external
makefile generators like configure, CMake, or qmake.

On Wed, Jun 23, 2010 at 6:41 PM, James Blackburn
<jamesblackburn@xxxxxxxxx> wrote:
>> 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?
> It can work for simple projects, but the bugs you describe indicate
> that no one's using it in anger...
> On the ManagedBuild side, we're using the generated makefile builds
> for two groups here which are building artefacts from  multiple
> inter-dependent eclipse projects.  These project-sets are growing in
> complexity every day and are starting to stress the MBS...  But so far
> it's working reasonably well.  We've been tackling issues as we find
> pain points and the projects grow (some of these patches are in
> bugzilla but not yet in CDT proper).
> In the long term, the internal builder would seem ideal, but without
> the generated makefiles, it's difficult to have confidence that the
> builder is doing the right thing. In my experience developers are very
> unforgiving if the IDE produces an incorrect build, where their
> hand-written makefile would have been perfect (of course...).  With
> the makefile generator, if something goes wrong, the intermediate
> builder output is there for review.
> There are a fair few outstanding issues with managedbuild and any
> contributions on that front would be very welcome.
> Cheers,
> James
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top