Re: Extensions, patch v16
От | Tom Lane |
---|---|
Тема | Re: Extensions, patch v16 |
Дата | |
Msg-id | 23371.1291995176@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Extensions, patch v16 (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Extensions, patch v16
Re: Extensions, patch v16 |
Список | pgsql-hackers |
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > "David E. Wheeler" <david@kineticode.com> writes: >>> What if $extension.control exists? Is it a byproduct of the .in file >>> from previous `make` run or a user file? What if we have both the .in >>> and the make variable because people are confused? Or both the make >>> variables and a .control and not .control.in? Etc... >> * Always remove $extension.control in the `clean` targets > Hell no, as you can bypass the .in mechanism and provide directly the > .control file. Are there any actual remaining use-cases for that sed step? It's certainly vestigial as far as the contrib modules are concerned: it would be simpler and more readable to replace MODULE_PATHNAME with $libdir in the sources. Unless somebody can point to a real-world use-case, I'd just as soon get rid of the .in files altogether while we're having this flag day. regards, tom lane
В списке pgsql-hackers по дате отправления: