Make the list of options in --help line up a little better and set
proper detailed descriptions on all options. Also set output text
on all options during the ./configure operation.

This will make it so that we can build gpfdist with or without
OpenSSL when doing the configure.
* Print a message that SSL is not supported if built without OpenSSL

As gpfdist will now be part of the gpdb build by default, we may just
treat it as part of gpdb core.
* Integrate gpfdist configure file to the top level configure and
  changed necessary files to accomadate the changes.
* Modify travis.yml for gpfdist structural changes
* Update gpfdist.c to use GP_VERSION from pg_config.h

Fix warning issues from transform.c
* There were many prototype warnings that was being mentioned.
  Added a headerfile for missing prototype warnings, also included the
  structs into the headerfile.

Replace src/port/glob.c
* src/port/glob.c is dead code at the moment and can be safely replaced by
  the windows changes from gpfdist/port

Check for libyaml:
* disable transformations for gpfdist if not found.

* Add configuration option for gpfdist
use --disable-gpfdist to turn off gpfdist build

Enable to run extension regression tests from top level makefile

* Add installcheck gpfdist into extensions
* Add check for enterprise targeted builds
* Pass apr config to gpfdist
* Add JAVA_HOME check

Authors:
Marbin Tan and Shujie Shang

Heikki suggested that we backport atomic operation from PostgreSQL 9.5 to
fix this

    commit b64d92f1
    Author: Andres Freund <andres@anarazel.de>
    Date:   Thu Sep 25 23:49:05 2014 +0200

    Add a basic atomic ops API abstracting away platform/architecture details.

    Several upcoming performance/scalability improvements require atomic
    operations. This new API avoids the need to splatter compiler and
    architecture dependent code over all the locations employing atomic
    ops.

    For several of the potential usages it'd be problematic to maintain
    both, a atomics using implementation and one using spinlocks or
    similar. In all likelihood one of the implementations would not get
    tested regularly under concurrency. To avoid that scenario the new API
    provides a automatic fallback of atomic operations to spinlocks. All
    properties of atomic operations are maintained. This fallback -
    obviously - isn't as fast as just using atomic ops, but it's not bad
    either. For one of the future users the atomics ontop spinlocks
    implementation was actually slightly faster than the old purely
    spinlock using implementation. That's important because it reduces the
    fear of regressing older platforms when improving the scalability for
    new ones.

    The API, loosely modeled after the C11 atomics support, currently
    provides 'atomic flags' and 32 bit unsigned integers. If the platform
    efficiently supports atomic 64 bit unsigned integers those are also
    provided.

    To implement atomics support for a platform/architecture/compiler for
    a type of atomics 32bit compare and exchange needs to be
    implemented. If available and more efficient native support for flags,
    32 bit atomic addition, and corresponding 64 bit operations may also
    be provided. Additional useful atomic operations are implemented
    generically ontop of these.

    The implementation for various versions of gcc, msvc and sun studio have
    been tested. Additional existing stub implementations for
    * Intel icc
    * HUPX acc
    * IBM xlc
    are included but have never been tested. These will likely require
    fixes based on buildfarm and user feedback.

    As atomic operations also require barriers for some operations the
    existing barrier support has been moved into the atomics code.

    Author: Andres Freund with contributions from Oskari Saarenmaa
    Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
    Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
        20131015123303.GH5300@awork2.anarazel.de,
        20131028205522.GI20248@awork2.anarazel.de

This patch replaces all occurrences of pgsql-bugs@postgresql.org with
bugs@greenplum.org. Pointers to the pgsql-bugs mailinglist in the code
remain as they re. Regression and BugBuster tests are also patched.

This patch merges the PostgreSQL 9.5 implementation of SSE4.2 into GPDB.
The SSE4.2 implementation was lifted right out of PostgreSQL without
change to make merging later PostgreSQL releases easier.

Update win32 configuration to support SSE4.2 runtime checks

This change was pulled from "src/include/pg_config.h.win32" from the
commits below.

configure.in changes, determining if cpu instruction for perfomring runtime
checks are availible, and moving some of the code to port SSE4.2 came from the
following PostgreSQL commits:

commit 3dc2d62d
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Apr 14 17:05:03 2015 +0300

    Use Intel SSE 4.2 CRC instructions where available.

    Modern x86 and x86-64 processors with SSE 4.2 support have special
    instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
    speed up CRC calculation.

    Whether the instructions can be used or not depends on the compiler and the
    target architecture. If generation of SSE 4.2 instructions is allowed for
    the target (-msse4.2 flag on gcc and clang), use them. If they are not
    allowed by default, but the compiler supports the -msse4.2 flag to enable
    them, compile just the CRC-32C function with -msse4.2 flag, and check at
    runtime whether the processor we're running on supports it. If it doesn't,
    fall back to the slicing-by-8 algorithm. (With the common defaults on
    current operating systems, the runtime-check variant is what you get in
    practice.)

    Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.

commit b4eb2d16
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Apr 14 19:56:00 2015 +0300
	On gcc and clang, the _mm_crc32_u8 and _mm_crc32_u64 intrinsics are not
	defined at all, when not building with -msse4.2. But on icc, they are.
	So we cannot assume that if those intrinsics are defined, we can always use
	them safely, we might still need the runtime check.

	To fix, check if the __SSE_4_2__ preprocessor symbol is defined. That's
	supposed to be defined only when the compiler is targeting a processor that
	has SSE 4.2 support.

	Per buildfarm members fulmar and okapi.

There are no translations for Greenplum-specific strings, so it seems like
a disservice to allow anyone to build with --enable-nls.

The PostgreSQL translation files were a bit of a hodge-podge too; they
seemed to be from PostgreSQL 8.4.1, but we still carried the bunch of
incomplete translations that were removed in PostgreSQL 8.4.1. Let's not
pretend that there's any sense in them, and just remove all .po files. If
we want to make NLS to work properly in the future, we can bring them back,
using some sensible versions. Another option would've been to replace them
with the REL8_2_0 versions, which would possibly have made merging with
upstream slightly easier, as you wouldn't get merge conflicts on the
removed files, but those conflicts are easy to deal with. Also, by removing
the files completely, we don't need to decide what to do with the
references to pgsql-bugs@postgresql.org in them (we're trying to replace
all those references with bugs@greenplum.org).

Update config to include gpopt and gpos header files.

This reverts commit c742462e.

Netsnmp exported strlcpy, so that when the configure script checked for
presence of strlcpy, it said "yes", even though it was only present when
linking with -lnetsnmp. That's exactly the same problem as mentioned
in configure.in for -ledit. Fix in the same way.

The USE_FORCE_PLAN option has been unused for a long time.

It's important to pay attention to compiler warnings, but -Werror isn't
buying us much at the moment. Firstly, there are a lot of warnings on modern
versions of gcc. I have to pass: "-Wno-error=unused-but-set-variable
-Wno-error=enum-compare -Wno-error=address -Wno-error=maybe-uninitialized"
to make it compile. More important than erroring out on warnings is to make
sure there are no warnings to begin with. Once we get to that state, any
warnings will stick out like sore thumb anyway, and you won't need -Werror
to make them more annoying.

We have a long way until we are 100% warning free, but most of the warnings
come from upstream code. They have been fixed in later versions of
PostgreSQL, so they will go away as we merge with upstream.

strange coding practices.

are both used.

Albe Laurenz

create our own.

than just numbers.

back-stamped for this.

infrastructure.

v8.2.0 is now released ...

standard functions.  Per report from Stefan Kaltenbrunner.

update for rc1

Tag as Beta3 ... two outstanding *known* bugs before RC1 ...

include it if it links properly.  It seems too risky to assume that
standard functions like pow() are not special-cased by the compiler.
Per report from Andreas Lange that build fails on Solaris cc compiler
with -fast.  Even though we don't consider that a supported option,
I'm worried that similar issues will arise with other compilers.

code relies on the checking macro actually being called at the end, or the
automatic undiversion will produce garbage.  These sort of implicit
side-effects undermine the modularity of the macros and happen to break the
ODBC driver which makes use of them.

Also put the warnings at the very end of configure, so there is an even
better chance of seeing them.

Also cut back on excessive use of *** to decorate configure error messages.
If it's an error message, you are sure to see it without any decoration.

max_stack_depth is not set to an unsafe value.

This commit also provides configure-time checking for <sys/resource.h>,
and cleans up some perhaps-unportable code associated with use of that
include file and getrlimit().

Buildfarm results from 'gazelle' show that there are indeed libedit
versions for which history.h is a needed header, even though it's
apparently been dropped entirely in other versions.  Grumble.

Per Bob Friesenhahn's report, this file is not supplied by some versions
of libedit, and even when it is supplied it seems to be just a link to
readline.h, so we don't need to include it anyway.
Also, ensure that we won't try to use a too-old version of Bison.
The previous coding would bleat but then use it anyway; better to invoke
the 'missing' script if any grammar files need to be rebuilt.

repeatedly.  Now that we don't have to worry about memory leaks from
glibc's qsort, we can safely put CHECK_FOR_INTERRUPTS into the tuplesort
comparators, as was requested a couple months ago.  Also, get rid of
non-reentrancy and an extra level of function call in tuplesort.c by
providing a variant qsort_arg() API that passes an extra void * argument
through to the comparison routine.  (We might want to use that in other
places too, I didn't look yet.)