RE: [cdt-dev] Internal builder status

["Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>]

Hi,

it is not a good idea to base the builder on the dependencies as found in the index. The main reasons why

I think so are:

* You don't want to have the dependency that the indexer has to complete before you can build. The current

  implementation of the internal builder probably does not even check whether the index is up to date or not.

* It is likely that the configuration of the indexer is not perfect. I have not seen many projects where the

  indexer does not report the one or other unresolved include file.

 

I think just like a makefile based build the internal builder needs to let the compiler output the dependencies

together with the object files and it needs to read and interpret these files.

 

Markus.

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Friday, June 25, 2010 12:31 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Internal builder status
Importance: Low

You can keep indexer configuration in sync with build configuration (which is called active build configuration), there is a preference for that. The downside is of course that everything gets reindexed on configuration switch. It really has nothing to do with internal builder, same problems with external one.

Andrew

On Thu, Jun 24, 2010 at 5:40 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:

That's a great point Chris. Having a different Indexer setting versus build really invalidates the internal build strategy.

On Jun 24, 2010 3:12 PM, "Chris Recoskie" <recoskie@xxxxxxxxxx> wrote:
>
> I believe there is an index-based dependency calculator which the internal
> builder uses. This has some flaws though as well, because it hinges on the
> index contents having been generated for the configuration that you are
> building. I think (correct me if I'm wrong) the indexer uses one static
> build configuration by default, so if you switch build configuration from
> say Debug to Release, it might not match what you're building.
>
> In the Debug vs Release case, in all likelihood, your code won't be
> including different headers, so it should work fine for that case 99% of
> the time. The bigger gotcha is if you have multiple configurations that
> target different platforms. Then the set of headers used by each
> configuration is more likely to diverge.
>
> ===========================
> Chris Recoskie
> Team Lead, IBM CDT and RDT
> IBM Toronto
>
>

> |------------>

> | From: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |James Blackburn <jamesblackburn@xxxxxxxxx> |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |06/24/2010 02:51 PM |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Re: [cdt-dev] Internal builder status |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Sent by: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |cdt-dev-bounces@xxxxxxxxxxx |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
> On 24 June 2010 19:11, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>> On Thu, Jun 24, 2010 at 2:08 PM, James Blackburn
>> <jamesblackburn@xxxxxxxxx> wrote:
>>> On 24 June 2010 18:56, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>>>> I certainly agree with that. If we had someone in there fixing these
>>>> bugs, which as you mention have been there since 6.0 and I think maybe
>>>> longer, then I'd have a different opinion, at least for the cases
>>>> Chris mentions where there is no pre-existing build files and where
>>>> make is not readily available (which isn't that many platforms any
>>>> more).
>>>
>>> I think Chris is on the ball in that this is somewhere we want to be
>>> eventually. As the build model feeds both the makefile generator and
>>> the internal builder, I've been focussing on getting the makefile
>>> builder right for my users.  As it stands there are some thorny
>>> platform build integration issues we need to overcome to make it
>>> 'seamless'.
>>
>> James correct me if I'm wrong, but the build model does not generate
>> the build dependencies does it? I thought that came from the gcc
>> compiler itself. At least it did a long time ago. It's the build
>> dependencies that I worry about and what would lead to most build
>> quality issues. If I change a header file, I want a guarantee that all
>> the source files that read that header file get rebuilt.
>
> Yes, you're right. I guess as a fall-back the the internal builder
> could generate and use the dependency list as make does.
> _______________________________________________
> 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