Skip site navigation (1) Skip section navigation (2)

Re: Constant changes (Re-Build)

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: luis garcia <ldgarc(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Constant changes (Re-Build)
Date: 2006-09-27 08:35:34
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
luis garcia wrote:
> Hi I'm a student from Valencia-Venezuela and I'm working with some
> other friends to make PostgreSQL allows the definition of Temporal
> Databases and their respective Selection, Insertion and some other
> functions needed to treat this paradigm  (all based in TSQL2 Query
> Language).

That's interesting. May I suggest that you take a look at a book called 
"Temporal Data & the Relational Model" by C.J. Date, Hugh Darwin and 
Nikos Lorentzos 
It describes the best approach I've seen this far to dealing with 
temporal data.

> Right now we are working directly on the source code and making
> different changes during the day, so I'd like to ask you which is the 
> better
> choice for re-building (I'm not sure if that is the right term) only the
> code
> files that I just have changed.
> I'm working on a Slow PC with not to many recourse, so every time I
> make (-configure/-make/-make-install/) i lose like 30 minutes of work,
> and I have been thinking in some other way to only re-configure the files
> I've recently changed.

Well, you don't need to run configure every time you want to build. If 
you just run "make", it will compile just the changes. I'd suggest 
running the configure with the --enable-depend option, so it picks up 
changes in header files better.

Also take a look at ccache ( And if you have 
more PCs to spare, you might want to set up distcc.

Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Markus SchaberDate: 2006-09-27 08:37:49
Subject: Re: jar in repository
Previous:From: Heikki LinnakangasDate: 2006-09-27 08:23:02
Subject: Re: Block B-Tree concept

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group