Re: failing to build preproc.c on solaris with sun studio - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: failing to build preproc.c on solaris with sun studio
Date
Msg-id 627a7628-c125-978f-72c4-4ae39ef70e9a@enterprisedb.com
Whole thread Raw
In response to Re: failing to build preproc.c on solaris with sun studio  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: failing to build preproc.c on solaris with sun studio
List pgsql-hackers
On 05.09.22 23:34, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> Why is this being proposed?
> 
> Andres is annoyed by the long build time of ecpg, which he has to
> wait for whether he wants to test it or not.  I could imagine that
> I might disable ecpg testing on my slowest buildfarm animals, too.
> 
> I suppose maybe we could compromise on inventing --with-ecpg but
> having it default to "on", so that you have to take positive
> action if you don't want it.

We already have "make all" vs. "make world" to build just the important 
stuff versus everything.  And we have "make world-bin" to build, 
approximately, everything except the slow stuff.  Let's try to work 
within the existing mechanisms.  For example, removing ecpg from "make 
all" might be sensible.

(Obviously, "all" is then increasingly becoming a lie.  Maybe a renaming 
like "all" -> "core" and "world" -> "all" could be in order.)

The approach with the make targets is better than a configure option, 
because it allows you to build a narrow set of things during development 
and then build everything for final confirmation, without having to 
re-run configure.  Also, it's less confusing for packagers.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Different compression methods for FPI
Next
From: Yura Sokolov
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types