Re: failing to build preproc.c on solaris with sun studio
От | Peter Eisentraut |
---|---|
Тема | Re: failing to build preproc.c on solaris with sun studio |
Дата | |
Msg-id | 627a7628-c125-978f-72c4-4ae39ef70e9a@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: failing to build preproc.c on solaris with sun studio (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: failing to build preproc.c on solaris with sun studio
|
Список | 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 по дате отправления: