[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Internal builder still experimental?
|
Hi Gerrit, Doug,
There was an opposite question to the dev list and bugzilla regarding
this sometime ago, i.e. initially the "Builder Settings" UI allowed to
perform an "Internal-to-External" switch for the tool-chains using
Internal Builder, there was a request to disable this.
One of the main reasons why we agreed with disabling this and made the
disabling was that it was not clear which external builder to choose
when selecting the "External Builder" option for the tool-chain with the
Internal Builder, i.e. there might be multiple external builders defined
Note that selecting the internal builder is still possible via the
builder selection tab of the "tool-chain editor" property page.
Another question I would like to raise is the difference in behavior of
the builder selection combos of the "tool-chain editor" and the "Builder
Settings" pages.
I. The "tool-chain editor" actually allows selecting any builder
available and is supposed to be used by advanced users only since
changing the builder as well as other tool-chain settings might result
in not being able to build the project, because the tools and builder
are not compatible with each other (e.g. because the tool's command line
generator generates the command line specific for the particular
builder)
II. The builder selection combo of the "Builder Settings" works as
follows:
1. The "Internal Builder" option remembers the current builder being
used enables the internal builder
2. The "External Builder" option enables the external builder that was
used before the Internal Builder was selected
This option is actually introduced for user convenience only (since its
functionality fully covered by the "tool-chain editor") and is supposed
to be used by any users since it does not seem to allow selecting the
wrong builder
I already saw users confused with having these two types of builder
selection options, so probably we could unify them, e.g. make the
builder selection of the "Builder Settings" behave in the same way as
the one of the "tool-chain editor", e.g. always allow selecting any
available builder.
What do you think?
Thanks,
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Sent: Monday, April 30, 2007 11:42 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Internal builder still experimental?
I guess the main reason is there's no external builder support is that I
didn't hook up a makefile generator. My intention with the MinGW
integration
is to support MinGW without requiring MSYS. So, since I have a lot to do
for
CDT 4, I skipped the external builder totally.
I guess the main issue I have with using the generated makefiles for
external build systems like cruisecontrol is that they are written
everytime
you build (or at least they used to be). You certainly wouldn't want to
check them into source control. That's why the whole build output
directory
is marked derived.
My vision is that we would create a makefile exporter that you could use
to
generate a makefile for external use. This is similar to how VC6 used to
work. Then you would have total control over it's format and output
location
and can be done only when necessary.
Feel free to raise a bug on this, though and we can discuss.
Doug
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Gerrit Brehmer
> Sent: Monday, April 30, 2007 3:25 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Internal builder still experimental?
>
> Hi Doug,
> is there a reason, why with new mingw toolset the makefile builder
isn't
> selectable? Internal builder is quite good and should be the default
> builder, but I need generated makefiles for my cruisecontrol
build-system
> and I think that the user should have the two options to build. Or are
> there any problems with mingw and makefile-builder?
>
> Best regards
> Gerrit Brehmer
>
> ----- Original Message ----
> From: Doug Schaefer <DSchaefer@xxxxxxx>
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Sent: Monday, April 30, 2007 7:57:01 PM
> Subject: RE: [cdt-dev] Internal builder still experimental?
>
>
> The internal builder is no longer experimental. It is the default
builder
> for the MinGW integration (so people don't have to distribute MSYS
with
> their MinGW tool chains). Please raise a bug on the wording and any
> problems
> found with the internal builder.
>
> Thanks,
> Doug Schaefer, QNX Software Systems
> Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
>
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On
> > Behalf Of Jason Montojo
> > Sent: Monday, April 30, 2007 1:39 PM
> > To: CDT General developers list.
> > Subject: [cdt-dev] Internal builder still experimental?
> >
> >
> > Hi everyone,
> >
> > When I build a managed project in CDT, I get the following messages
in
> the
> > console:
> >
> > **** Build of configuration Debug for project zxc ****
> >
> > **** Internal Builder is used for build ****
> > **** NOTE: Internal Builder is experimental currently ****
> >
> > Should we keep this wording for the 4.0 release? Saying it's
> experimental
> > could potentially scare away some users. At the same time, users
would
> > have a bit more patience with it since they might not expect it to
be
> > release quality. I'm wondering what everyone else's thoughts are on
> this.
> >
> > Thanks,
> >
> > Jason Montojo
> > IBM CDT Team
> > IBM Toronto Lab
> > 905-413-5228
> > jmontojo@xxxxxxxxxx
> >
> > _______________________________________________
> > 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
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> 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
