cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance issues with Cons


From: david . weidenkopf
Subject: Re: Performance issues with Cons
Date: Mon, 7 Oct 2002 10:48:59 -0700


Warren wrote:
I certainly understand that ---  however, as I said in my other post, I'd like a
way for developers to say: "I'm pretty sure that the dependencies haven't
changed since the last time you built them - please don't rescan everything".


Here's my understanding, hopefully someone will correct me if it's wrong. In theory this is called pruning. The cons docs say you can use  a regex to "prune" what cons will build. I have tried it without much success, but that could definitely be pilot error. However, we have implemented a different strategy. Our strategy is to only let cons know about what we want to build. So it is not doing full dependency checking. So instead of directing cons to filter what it knows about, we are filtering what is input to cons.

Does that help?

David Weidenkopf


address@hidden
Sent by: address@hidden

10/07/2002 10:21 AM

       
        To:        David Weidenkopf/ATL-BTL/MS/address@hidden
        cc:        address@hidden
        Subject:        Re: Performance issues with Cons

        Classification:        







> The performance penalty is the cost of correctness. Cons is analyzing every
dependency before it does anything.

I certainly understand that ---  however, as I said in my other post, I'd like a
way for developers to say: "I'm pretty sure that the dependancies haven't
changed since the last time you built them - please don't rescan everything".

>You might find the scripting capabilities of gnu-make lacking. We looked at
using gnu-make, but we got our Cons
> prototype working so quickly we abandoned the thought.

I've used gnu-make enough to know that I really don't like it...  Switching to
gnu-make is really quite low on my list of priorities...  If we can't figure out
how to do this with cons, my inclination is to suggest we switch to scons, which
already supports a feature like this...

Frankly, I'm tempted to suggest switching to scons anyways, since it doesn't
look like there's a lot of interest in working on cons, but scons still seems to
have a fairly active development community...

Warren




_______________________________________________
address@hidden
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]