Re: Extensions makefiles - coverage

From: Ronan Dunklau <rdunklau(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions makefiles - coverage
Date: 2013-09-24 06:44:42
Message-ID: 1526670.BGjqRqbRiH@ronan_laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sunday 22 September 2013 01:34:53 Peter Eisentraut wrote:
> On Thu, 2013-07-25 at 17:07 +0200, Ronan Dunklau wrote:
> > I am using approximatively the layout that was proposed here:
> > http://www.postgresql.org/message-id/51BB1B6E.2070705@dunslane.net
> > It looks like everything is hard-coded to take the source and the
> > gcda, gcno files in the base directory, but these files lay in a src
> > directory with the proposed layout.
>
> The PostgreSQL build system isn't going to work very well if you build
> files outside of the current directory. If you want to put your source
> files into a src/ subdirectory, then your top-level makefile should to a
> $(MAKE) -C src, and you need to have a second makefile in the src
> directory. If you do that, then the existing coverage targets will work
> alright, I think.

The PGXS build system allows for the definition of an OBJS variable, which
works fine with almost every other make target.

Maybe we need to take a step back, and think about what kind of extension
layouts we want to support ?

At the time of this writing, the HOW TO on http://manager.pgxn.org/howto
"strongly encourage" to put all C-files in an src directory.

As a result, many extensions on pgxn use this layout. It would be great not to
have to change them to measure code coverage.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-09-24 08:15:08 Re: logical changeset generation v6
Previous Message Chris Travers 2013-09-24 04:59:33 Re: 9.3 Json & Array's