On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote: > On 2015-08-15 12:47:09 -0400, Noah Misch wrote: > > $ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1' > > pg_resetxlog.o: In function `fastgetattr': > > /data/nmisch/src/pg/postgresql/src/bin/pg_resetxlog/../../../src/include/access/htup_details.h:754: > > undefined reference to `nocachegetattr' > > pg_resetxlog.o: In function `heap_getattr': > > /data/nmisch/src/pg/postgresql/src/bin/pg_resetxlog/../../../src/include/access/htup_details.h:783: > > undefined reference to `heap_getsysattr'
> What's the advantage of using STATIC_IF_INLINE over just #ifndef > FRONTEND? > In fact STATIC_IF_INLINE does *not* even help here unless we also detect > compilers that support inlining but balk when inline functions reference > symbols not available. There was an example of that in the buildfarm as > of 2014, c.f. a9baeb361d63 . We'd have to disable inlining for such > compilers. Neat; I didn't know that. Solaris Studio 12.3 (newest version as of Oct 2014) still does that when optimization is disabled, and I place sufficient value on keeping inlining enabled for such a new compiler. The policy would then be (already is?) to wrap in "#ifdef FRONTEND" any inline function that uses a backend symbol. When a header is dedicated to such functions, we might avoid the whole header in the frontend instead of wrapping each function. That policy works for me. On Sat, Aug 15, 2015 at 01:48:17PM -0400, Tom Lane wrote: > Realistically, with what we're doing now, we *have* broken things for > stupid-about-inlines compilers; because even if everything in the core > distribution builds, we've almost certainly created failures for > third-party modules that need to #include headers that no contrib > module includes. Only FRONTEND code (e.g. repmgr, pg_reorg) will be at hazard, not ordinary third-party (backend) modules. We could have a test frontend that includes every header minus a blacklist, but I don't think it's essential. External FRONTEND code is an order of magnitude less common than external backend code. Unlike backend module development, we don't document the existence of the FRONTEND programming environment. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
