Re: Use "?=" operator for a contrib makefile in documentation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Use "?=" operator for a contrib makefile in documentation
Дата
Msg-id 194794.1759154422@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Use "?=" operator for a contrib makefile in documentation  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Use "?=" operator for a contrib makefile in documentation
Список pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> On 25.09.25 15:17, Maxim Orlov wrote:
>> I think that the Makefile should be written so that variable values,
>> specifically, PG_CONFIG, can be given to it from the environment rather
>> than the make command line. As a result, using the "?=" operator rather
>> than "=" to set a default value to the PG_CONFIG variable appears more
>> acceptable.

> I think the current text is preferable.  This allows running
> make PG_CONFIG=...
> so that you can pick a different PostgreSQL installation for a 
> particular build.

AFAICT that would still work with ?=.  Nonetheless, I agree with
Peter that we shouldn't change this advice (much less change all our
Makefiles that do it like that).  The reason is that the gmake manual
advises caution in the use of this feature:

   Thus, by setting the variable 'CFLAGS' in your environment, you can
   cause all C compilations in most makefiles to use the compiler switches
   you prefer.  This is safe for variables with standard or conventional
   meanings because you know that no makefile will use them for other
   things.
   ...
   Other use of variables from the environment is not recommended.  It
   is not wise for makefiles to depend for their functioning on environment
   variables set up outside their control, since this would cause different
   users to get different results from the same makefile.  This is against
   the whole purpose of most makefiles.

(This is in "Variables from the Environment", section 6.10 in the
gmake manual version that I have at hand.)

            regards, tom lane



В списке pgsql-hackers по дате отправления: