<?xml version="1.0" encoding="UTF-8" standalone="yes"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-us"><id>https://blog.pgxn.org/tags/make/</id><title>Make</title><updated>2012-04-11T16:36:00Z</updated><link rel="self" type="application/atom+xml" href="https://blog.pgxn.org/tags/make/feed.xml"/><link rel="alternate" type="text/html" href="https://blog.pgxn.org/tags/make/"/><author><name>The PGXN Maintainers</name></author><generator uri="https://gohugo.io/" version="0.167.0">Hugo</generator><entry><id>https://blog.pgxn.org/post/20908326485</id><title type="html">Lose USE_PGXS in your Makefiles</title><link rel="alternate" type="text/html" href="https://blog.pgxn.org/2012/lose-use-pgxs/"/><updated>2026-10-07T16:13:48Z</updated><published>2012-04-11T16:36:00Z</published><author><name>David E. Wheeler</name></author><category scheme="https://blog.pgxn.org/tags" term="extension" label="Extension"/><category scheme="https://blog.pgxn.org/tags" term="use_pgxs" label="USE_PGXS"/><category scheme="https://blog.pgxn.org/tags" term="makefile" label="Makefile"/><category scheme="https://blog.pgxn.org/tags" term="make" label="make"/><category scheme="https://blog.pgxn.org/tags" term="pg_config" label="pg_config"/><category scheme="https://blog.pgxn.org/tags" term="contrib" label="contrib"/><summary type="html"><![CDATA[<p>Traditionally, folks have created extensions for PostgreSQL by copying one of
the <a href="https://www.postgresql.org/docs/current/static/contrib.html">contrib modules</a> and hacking it into something new. One of the things
that comes along for the ride is the <code>Makefile</code> (<a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=contrib/isn/Makefile;hb=HEAD">example</a>). As a result,
there are a lot of third-party extensions that use the <code>USE_PGXS</code> variable.</p>
<p>A bit of background. The core contrib extensions generally rely on a relative
path to include the core <code>Makefile</code>s needed to build the extension. Because
they ship with the core distribution, they can generally expect that the core
has already been compiled, the necessary <code>Makefile</code>s have been created, and
that they should be built against them. All the assumptions are that the
extensions should be built against the source tree in which they are
distributed. So there is no need to use <a href="https://www.postgresql.org/docs/current/static/app-pgconfig.html"><code>pg_config</code></a> to find <a href="https://www.postgresql.org/docs/current/static/extend-pgxs.html">PGXS</a>; it
already knows where to find what it needs.</p>]]></summary><content type="html" xml:base="https://blog.pgxn.org/" xml:space="preserve"><![CDATA[<p>Traditionally, folks have created extensions for PostgreSQL by copying one of
the <a href="https://www.postgresql.org/docs/current/static/contrib.html">contrib modules</a> and hacking it into something new. One of the things
that comes along for the ride is the <code>Makefile</code> (<a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=contrib/isn/Makefile;hb=HEAD">example</a>). As a result,
there are a lot of third-party extensions that use the <code>USE_PGXS</code> variable.</p>
<p>A bit of background. The core contrib extensions generally rely on a relative
path to include the core <code>Makefile</code>s needed to build the extension. Because
they ship with the core distribution, they can generally expect that the core
has already been compiled, the necessary <code>Makefile</code>s have been created, and
that they should be built against them. All the assumptions are that the
extensions should be built against the source tree in which they are
distributed. So there is no need to use <a href="https://www.postgresql.org/docs/current/static/app-pgconfig.html"><code>pg_config</code></a> to find <a href="https://www.postgresql.org/docs/current/static/extend-pgxs.html">PGXS</a>; it
already knows where to find what it needs.</p>
<p>But as extensions, there is still the possibility that one might want to build
them against an existing installation of PostgreSQL, or an older version than
the source with which they&rsquo;re distributed. So the core hackers provided the
<code>USE_PGXS</code> variable so that one can in effect tell <code>make</code>, &ldquo;Don&rsquo;t build
against the local source tree, but find PGXS for some other install and build
against that, instead.&rdquo; It was expected to be exceptional, since most folks
would build against the local source tree, and not a big deal to make anyone
else build it with:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-sh" data-lang="sh"><span class="line"><span class="cl">make <span class="nv">USE_PGXS</span><span class="o">=</span><span class="m">1</span>
</span></span></code></pre></div><p>Today things are different. There is a growing ecosystem of third party
extensions on <a href="https://pgxn.org/">PGXN</a>, <a href="https://pgfoundry.org/">pgFoundry</a>, <a href="https://github.com/">GitHub</a>, and <a href="https://bitbucket.org/">Bitbucket</a>, and obviously
they&rsquo;re not distributed with the PostgreSQL core. For these extensions, there
is no surrounding PostgreSQL source code to automatically include, so they
<em>must</em> use <code>pg_config</code> to find PGXS in order build.</p>
<p>Yet, there are quite a few third-party extensions that nevertheless assume
that they are in the <code>contrib</code> directory of the PostgreSQL source code
distribution, and so still have the <code>USE_PGXS</code> variable. The <a href="https://api.pgxn.org/src/twitter_fdw/twitter_fdw-1.0.0/Makefile">twitter_ftw
1.0.0 <code>Makefile</code></a> is a recent example. Just like core extensions, it has this
code:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" data-lang="makefile"><span class="line"><span class="cl"><span class="err">ifdef</span> <span class="err">USE_PGXS</span>
</span></span><span class="line"><span class="cl"><span class="nv">PG_CONFIG</span> <span class="o">=</span> pg_config
</span></span><span class="line"><span class="cl"><span class="nv">PGXS</span> <span class="o">:=</span> <span class="k">$(</span>shell <span class="k">$(</span>PG_CONFIG<span class="k">)</span> --pgxs<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">PGXS</span><span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="err">else</span>
</span></span><span class="line"><span class="cl"><span class="nv">subdir</span> <span class="o">=</span> contrib/twitter_fdw
</span></span><span class="line"><span class="cl"><span class="nv">top_builddir</span> <span class="o">=</span> ../..
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">top_builddir</span><span class="k">)</span><span class="err">/src/Makefile.global</span>
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">top_srcdir</span><span class="k">)</span><span class="err">/contrib/contrib-global.mk</span>
</span></span><span class="line"><span class="cl"><span class="err">endif</span>
</span></span></code></pre></div><p>Because Hitoshi-san originally copied the <code>Makefile</code> from a core extension, it
still assumes it will be distributed in core by default. And as I said, there
are quite a few third-party extensions that exhibit this pattern.</p>
<p>And now the <a href="https://en.wikipedia.org/wiki/Public_service_announcement">PSA</a>: <strong>Please don&rsquo;t use <code>USE_PGXS</code> in PostgreSQL extension
<code>Makefile</code>s.</strong></p>
<p>Not only is it unnecessary, it makes no sense for third-party extensions. They
should <em>always</em> assume that they need to use <code>pg_config</code> to find PGXS. If you
have an extension <code>Makefile</code> with <code>USE_PGXS</code> like twitter_ftw 1.0.0 did, you
should change it to something like this (as Hitoshi-san did in the
<a href="https://api.pgxn.org/src/twitter_fdw/twitter_fdw-1.0.1/Makefile">twitter_ftw 1.0.1 <code>Makefile</code></a>):</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" data-lang="makefile"><span class="line"><span class="cl"><span class="nv">PG_CONFIG</span> <span class="o">=</span> pg_config
</span></span><span class="line"><span class="cl"><span class="nv">PGXS</span> <span class="o">:=</span> <span class="k">$(</span>shell <span class="k">$(</span>PG_CONFIG<span class="k">)</span> --pgxs<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">PGXS</span><span class="k">)</span>
</span></span></code></pre></div><p>That&rsquo;s it. I am asking you to <em>make your <code>Makefile</code> simpler.</em></p>
<hr>
<p><em>An Aside</em></p>
<p>There is <em>one</em> situation in which you might need to include the core contrib
<code>Makefile</code>s. And it&rsquo;s pretty unusual. If you need to support PostgreSQL 8.1 or
earlier, <code>pg_config</code> will not be able to tell you where to find PGXS. So users
will have to copy the extension source directory into the PostgreSQL source
<code>contrib/</code> directory and build from there. They will need a way to tell <code>make</code>
<em>not</em> to use PGXS. In this one unusual case, I suggest you add a <code>NO_PGXS</code>
variable. <a href="https://api.pgxn.org/src/pgtap/pgtap-0.90.0/Makefile">pgTAP&rsquo;s <code>Makefile</code></a> provides an example. But honestly, very few
extensions need to support PostgreSQL 8.1 (the oldest release currently
supported by the core hackers is <em>8.3!</em>), so make use of this pattern only if
absolutely necessary.</p>
<p>Otherwise, please don&rsquo;t use <code>USE_PGXS</code>.</p>
<hr>
<p>If you want a complete guide to creating your extension <code>Makefile</code>, have a
look at the <a href="https://manager.pgxn.org/howto">PGXN Howto</a>, which includes some detailed examples that include
support for pre- and post-<a href="https://www.postgresql.org/docs/current/static/sql-createextension.html"><code>CREATE EXTENSION</code></a> support. The <a href="https://www.postgresql.org/docs/current/static/extend-pgxs.html">PGXS</a> docs
contain additional details about all the <code>Makefile</code> variables you can use to
simplify extension configuration and installation. Check &rsquo;em out.</p>
]]></content></entry><entry><id>https://blog.pgxn.org/post/4783001135</id><title type="html">Extension Makefiles for PostgreSQL 9.1</title><link rel="alternate" type="text/html" href="https://blog.pgxn.org/2011/extension-makefiles/"/><updated>2026-10-07T16:13:48Z</updated><published>2011-04-20T19:29:00Z</published><author><name>David E. Wheeler</name></author><category scheme="https://blog.pgxn.org/tags" term="extension" label="Extension"/><category scheme="https://blog.pgxn.org/tags" term="makefile" label="Makefile"/><category scheme="https://blog.pgxn.org/tags" term="make" label="make"/><category scheme="https://blog.pgxn.org/tags" term="pgxs" label="Pgxs"/><category scheme="https://blog.pgxn.org/tags" term="pg_config" label="pg_config"/><summary type="html"><![CDATA[<p>In order to keep distribution packaging as simple as possible, I worked up
this <code>Makefile</code> some time ago:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" data-lang="makefile"><span class="line"><span class="cl"><span class="nv">DATA</span> <span class="o">=</span> <span class="k">$(</span>wildcard sql/*.sql<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">DOCS</span> <span class="o">=</span> <span class="k">$(</span>wildcard doc/*.txt<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">TESTS</span> <span class="o">=</span> <span class="k">$(</span>wildcard test/sql/*.sql<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">REGRESS</span> <span class="o">=</span> <span class="k">$(</span>patsubst test/sql/%.sql,%,<span class="k">$(</span>TESTS<span class="k">))</span>
</span></span><span class="line"><span class="cl"><span class="nv">REGRESS_OPTS</span> <span class="o">=</span> --inputdir<span class="o">=</span><span class="nb">test</span> --load-language<span class="o">=</span>plpgsql
</span></span><span class="line"><span class="cl"><span class="nv">MODULES</span> <span class="o">=</span> <span class="k">$(</span>patsubst %.c,%,<span class="k">$(</span>wildcard src/*.c<span class="k">))</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">PG_CONFIG</span> <span class="o">=</span> pg_config
</span></span><span class="line"><span class="cl"><span class="nv">PGXS</span> <span class="o">:=</span> <span class="k">$(</span>shell <span class="k">$(</span>PG_CONFIG<span class="k">)</span> --pgxs<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">PGXS</span><span class="k">)</span>
</span></span></code></pre></div><p>The nice thing about this code is that it has nothing specific to a
distribution in it. It figures out what SQL files there are, what doc files
there are, and what C files need compiling by just looking in the <code>sql</code>,
<code>doc</code>, and <code>src</code> directories, respectively. It also specifies that tests are
in the <code>test</code> directory. About the only thing I&rsquo;ve customized here is adding
<code>--load-language=plpgsql</code> to <code>REGRESS_OPTS</code>, as the tests for the distribution
I&rsquo;ve copied this from require PL/pgSQL to run. Simple, and anyone can use it
with very little need to tweak it, as long as they don&rsquo;t mind storing their
files in the specified directories.</p>]]></summary><content type="html" xml:base="https://blog.pgxn.org/" xml:space="preserve"><![CDATA[<p>In order to keep distribution packaging as simple as possible, I worked up
this <code>Makefile</code> some time ago:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" data-lang="makefile"><span class="line"><span class="cl"><span class="nv">DATA</span> <span class="o">=</span> <span class="k">$(</span>wildcard sql/*.sql<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">DOCS</span> <span class="o">=</span> <span class="k">$(</span>wildcard doc/*.txt<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">TESTS</span> <span class="o">=</span> <span class="k">$(</span>wildcard test/sql/*.sql<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">REGRESS</span> <span class="o">=</span> <span class="k">$(</span>patsubst test/sql/%.sql,%,<span class="k">$(</span>TESTS<span class="k">))</span>
</span></span><span class="line"><span class="cl"><span class="nv">REGRESS_OPTS</span> <span class="o">=</span> --inputdir<span class="o">=</span><span class="nb">test</span> --load-language<span class="o">=</span>plpgsql
</span></span><span class="line"><span class="cl"><span class="nv">MODULES</span> <span class="o">=</span> <span class="k">$(</span>patsubst %.c,%,<span class="k">$(</span>wildcard src/*.c<span class="k">))</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">PG_CONFIG</span> <span class="o">=</span> pg_config
</span></span><span class="line"><span class="cl"><span class="nv">PGXS</span> <span class="o">:=</span> <span class="k">$(</span>shell <span class="k">$(</span>PG_CONFIG<span class="k">)</span> --pgxs<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">PGXS</span><span class="k">)</span>
</span></span></code></pre></div><p>The nice thing about this code is that it has nothing specific to a
distribution in it. It figures out what SQL files there are, what doc files
there are, and what C files need compiling by just looking in the <code>sql</code>,
<code>doc</code>, and <code>src</code> directories, respectively. It also specifies that tests are
in the <code>test</code> directory. About the only thing I&rsquo;ve customized here is adding
<code>--load-language=plpgsql</code> to <code>REGRESS_OPTS</code>, as the tests for the distribution
I&rsquo;ve copied this from require PL/pgSQL to run. Simple, and anyone can use it
with very little need to tweak it, as long as they don&rsquo;t mind storing their
files in the specified directories.</p>
<p>Today, I&rsquo;m updating my distributions to support PostgreSQL 9.1&rsquo;s new
<code>CREATE EXTENSION</code> syntax, but I want to continue supporting older versions of
PostgreSQL, as well. Basically, this means that the files listed in the <code>DATA</code>
variable vary based on the version of PostgreSQL you&rsquo;re installing against.
Here are the additional things the <code>Makefile</code> needs to do:</p>
<ul>
<li>If installing against PostgreSQL less than version 9.1, exclude files in
<code>DATA</code> that contain <code>--</code>. Such files are are migration scripts, which aren&rsquo;t
supported before 9.1.</li>
<li>If installing against PostgreSQL greater than or equal to 9.1:
<ul>
<li>Copy the files <code>sql/$EXTENSION.sql</code> and <code>sql/$EXTENSION--unpackaged.sql</code>
to <code>sql/$EXTENSION--$EXTVERSION.sql</code> and
<code>sql/$EXTENSION--npackated--$EXTVERSION.sql</code>, respectively.
<code>CREATE EXTENSION</code> requires that the version string be in migration file
name. I&rsquo;d rather not have to rename the file in my repository before every
release (and I&rsquo;d rather keep it without the version for  9.1 anyway), so
it needs to be copied.</li>
<li>Add the new <code>sql/$EXTENSION--$VERSION.sql</code> file to <code>EXTRA_CLEAN</code>.</li>
<li>Include only files in <code>DATA</code> that contain <code>--</code>. There&rsquo;s no need to install
the original file without the version number, or any uninstall file,
either, since it&rsquo;s not needed on 9.1 anymore.</li>
</ul>
</li>
</ul>
<p>I&rsquo;ve been trying to figure out how to modify my standard <code>Makefile</code> to support
these changes, without requiring a lot of tweaking, so that other folks can
easily use it in the future. Thanks to help from <a href="https://people.planetpostgresql.org/andrew/">Andrew Dunstan</a>, this is
what I&rsquo;ve come up with:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" data-lang="makefile"><span class="line"><span class="cl"><span class="nv">EXTENSION</span><span class="o">=</span>semver
</span></span><span class="line"><span class="cl"><span class="nv">EXTVERSION</span><span class="o">=</span>0.2.2
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">DATA</span> <span class="o">=</span> <span class="k">$(</span>filter-out <span class="k">$(</span>wildcard sql/*--*.sql<span class="k">)</span>,<span class="k">$(</span>wildcard sql/*.sql<span class="k">))</span>
</span></span><span class="line"><span class="cl"><span class="nv">DOCS</span> <span class="o">=</span> <span class="k">$(</span>wildcard doc/*.txt<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">TESTS</span> <span class="o">=</span> <span class="k">$(</span>wildcard test/sql/*.sql<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">REGRESS</span> <span class="o">=</span> <span class="k">$(</span>patsubst test/sql/%.sql,%,<span class="k">$(</span>TESTS<span class="k">))</span>
</span></span><span class="line"><span class="cl"><span class="nv">REGRESS_OPTS</span> <span class="o">=</span> --inputdir<span class="o">=</span><span class="nb">test</span> --load-language<span class="o">=</span>plpgsql
</span></span><span class="line"><span class="cl"><span class="nv">MODULES</span> <span class="o">=</span> <span class="k">$(</span>patsubst %.c,%,<span class="k">$(</span>wildcard src/*.c<span class="k">))</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">PG_CONFIG</span> <span class="o">=</span> pg_config
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">VERSION</span>     <span class="o">=</span> <span class="k">$(</span>shell <span class="k">$(</span>PG_CONFIG<span class="k">)</span> --version <span class="p">|</span> awk <span class="s1">&#39;{print $$2}&#39;</span><span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">PGVER_MAJOR</span> <span class="o">=</span> <span class="k">$(</span>shell <span class="nb">echo</span> <span class="k">$(</span>VERSION<span class="k">)</span> <span class="p">|</span> awk -F. <span class="s1">&#39;{ print ($$1 + 0) }&#39;</span><span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="nv">PGVER_MINOR</span> <span class="o">=</span> <span class="k">$(</span>shell <span class="nb">echo</span> <span class="k">$(</span>VERSION<span class="k">)</span> <span class="p">|</span> awk -F. <span class="s1">&#39;{ print ($$2 + 0) }&#39;</span><span class="k">)</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="err">ifeq</span> <span class="err">(</span><span class="k">$(</span><span class="nv">PGVER_MAJOR</span><span class="k">)</span><span class="err">,</span> <span class="err">9)</span>
</span></span><span class="line"><span class="cl"><span class="err">ifneq</span> <span class="err">(</span><span class="k">$(</span><span class="nv">PGVER_MINOR</span><span class="k">)</span><span class="err">,</span> <span class="err">0)</span>
</span></span><span class="line"><span class="cl"><span class="nf">all</span><span class="o">:</span> <span class="n">sql</span>/<span class="k">$(</span><span class="nv">EXTENSION</span><span class="k">)</span>--<span class="k">$(</span><span class="nv">EXTVERSION</span><span class="k">)</span>.<span class="n">sql</span> <span class="n">sql</span>/<span class="k">$(</span><span class="nv">EXTENSION</span><span class="k">)</span>--<span class="n">unpackaged</span>--<span class="k">$(</span><span class="nv">EXTVERSION</span><span class="k">)</span>.<span class="n">sql</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nf">sql/$(EXTENSION)--$(EXTVERSION).sql</span><span class="o">:</span> <span class="n">sql</span>/<span class="k">$(</span><span class="nv">EXTENSION</span><span class="k">)</span>.<span class="n">sql</span>
</span></span><span class="line"><span class="cl">    cp $&lt; <span class="nv">$@</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nf">sql/$(EXTENSION)--unpackaged--$(EXTVERSION).sql</span><span class="o">:</span> <span class="n">sql</span>/<span class="k">$(</span><span class="nv">EXTENSION</span><span class="k">)</span>--<span class="n">unpackaged</span>.<span class="n">sql</span>
</span></span><span class="line"><span class="cl">    cp $&lt; <span class="nv">$@</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">DATA</span> <span class="o">=</span> <span class="k">$(</span>filter-out sql/<span class="k">$(</span>EXTENSION<span class="k">)</span>--unpackaged.sql,<span class="k">$(</span>wildcard sql/*--*.sql<span class="k">))</span> sql/<span class="k">$(</span>EXTENSION<span class="k">)</span>--<span class="k">$(</span>EXTVERSION<span class="k">)</span>.sql
</span></span><span class="line"><span class="cl"><span class="nv">EXTRA_CLEAN</span> <span class="o">=</span> sql/<span class="k">$(</span>EXTENSION<span class="k">)</span>--<span class="k">$(</span>EXTVERSION<span class="k">)</span>.sql sql/<span class="k">$(</span>EXTENSION<span class="k">)</span>--unpackaged--<span class="k">$(</span>EXTVERSION<span class="k">)</span>.sql
</span></span><span class="line"><span class="cl"><span class="err">endif</span>
</span></span><span class="line"><span class="cl"><span class="err">endif</span>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="nv">PGXS</span> <span class="o">:=</span> <span class="k">$(</span>shell <span class="k">$(</span>PG_CONFIG<span class="k">)</span> --pgxs<span class="k">)</span>
</span></span><span class="line"><span class="cl"><span class="err">include</span> <span class="k">$(</span><span class="nv">PGXS</span><span class="k">)</span>
</span></span></code></pre></div><p>This is not exactly ideal, but not <em>too</em> bad. It&rsquo;s not quite the drop-in
version we had before, because now the first line needs to name the extension
we&rsquo;re distributing, and the second needs to specify the version (and would
then need to be updated for every release). Maybe they could be read from the
control file somehow? Other than that, you should be able to just forget the
rest of the file (mostly). Here&rsquo;s how it addresses the above requirements:</p>
<ul>
<li>To exclude files with <code>--</code> in them on  9.1, the first <code>DATA</code> line filters
them out:</li>
</ul>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" data-lang="makefile"><span class="line"><span class="cl"><span class="nv">DATA</span> <span class="o">=</span> <span class="k">$(</span>filter-out <span class="k">$(</span>wildcard sql/*--*.sql<span class="k">)</span>,<span class="k">$(</span>wildcard sql/*.sql<span class="k">))</span>
</span></span></code></pre></div><ul>
<li>
<p>Next, we need to know if we&rsquo;re on 9.1 or higher. So we use
<code>pg_config --version</code> to get the version number and some <code>awk</code> stuff to get
the major and minor parts. Then, if the major version is 9 and the minor is
<em>not</em> 0, we:</p>
<ul>
<li>Add <code>sql/$(EXTENSION)--$(EXTVERSION).sql</code> and
<code>sql/$(EXTENSION)--unpackaged--$(EXTVERSION).sql</code> as dependencies of the
<code>all</code> rule (which is the default PGXS rule).</li>
<li>Add the <code>sql/$(EXTENSION)--$(EXTVERSION).sql</code> and
<code>sql/$(EXTENSION)--unpackated--$(EXTVERSION).sql</code> rules, which copy
<code>sql/$(EXTVERVERSION).sql</code> and <code>sql/$(EXTVERVERSION)--unpackaged.sql</code>
files. Of course this assumes that such files exist.</li>
<li>Add <code>sql/$(EXTENSION)--$(EXTVERSION).sql</code> and
<code>sql/$(EXTENSION)--unpackaged--$(EXTVERSION).sql</code> to <code>EXTRA_CLEAN</code>, so
that they&rsquo;ll be deleted by <code>make clean</code>.</li>
<li>Set <code>DATA</code> again, this time to include <em>only</em> files with <code>--</code> in them,
except for <code>sql/$(EXTENSION)--unpackaged.sql</code>.</li>
</ul>
</li>
</ul>
<p>And with that, it works. But it has some disadvantages over the previous, very
simple <code>Makefile</code> I&rsquo;ve been using up to now:</p>
<ul>
<li>One must modify it for every release, if only to set <code>EXTVERSION</code>.</li>
<li>It relies more on Unix tools than previously, specifically <code>awk</code>. I&rsquo;m not
sure how big a deal this is in practice; the <a href="https://github.com/theory/pgtap/blob/master/Makefile">pgTAP Makefile</a> has been
relying on <code>awk</code> an even worse gymnastics for some time and no one has
complained.</li>
<li>It&rsquo;s not perfectly future-proof. It will need to be modified when PostgreSQL
10.0.0 is released, and again when 11.0.0 is released.</li>
<li>It won&rsquo;t handle a distribution with multiple extension in it. I don&rsquo;t even
want to think about that.</li>
</ul>
<p>Suggestions for ways to eliminate these shortcomings would be greatly
appreciated, especially if it allows use extension authors to get back to
something as simple as the first example at the top of this post.</p>
<p><strong>UPDATE:</strong> Added the <code>unpackaged</code> bits I didn&rsquo;t realize I needed until after
I&rsquo;d released a new version of <a href="https://pgxn.org/dist/semver/">semver</a> and discovered that the &ldquo;unpackaged&rdquo;
script needs to always be tied to the default version.</p>
]]></content></entry></feed>