libzorpll pollute the define space with general variables

[mochrul]

I create this issue here, because there is no option in libzorpll to open an issue.

So, the libzorpconfig.h is a created by the configure.in. This config file contains the options checked by the configure.

Unfortunately the autoconf add some variables into this, which is the same for all projects. Therefore when zorp, which has its own config.h include bot, this options are redefined.

The problematic variables are the following:

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT ""

/* Define to the full name of this package. */
#define PACKAGE_NAME ""

/* Define to the full name and version of this package. */
#define PACKAGE_STRING ""

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME ""

/* Define to the home page for this package. */
#define PACKAGE_URL ""

/* Define to the version of this package. */
#define PACKAGE_VERSION ""

And when compiling the zorp, we get this warnings::

In file included from ./zorp/zorp.h:37:0,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
./zorp/zorpconfig.h:110:0: warning: "PACKAGE_NAME" redefined
 #define PACKAGE_NAME "zorp"

In file included from /usr/include/zorp/zorplib.h:23:0,
                 from /usr/include/zorp/misc.h:13,
                 from ./zorp/zorp.h:34,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
/usr/include/zorp/zorplibconfig.h:173:0: note: this is the location of the previous definition
 #define PACKAGE_NAME ""

In file included from ./zorp/zorp.h:37:0,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
./zorp/zorpconfig.h:113:0: warning: "PACKAGE_STRING" redefined
 #define PACKAGE_STRING "zorp 6.0.8"

In file included from /usr/include/zorp/zorplib.h:23:0,
                 from /usr/include/zorp/misc.h:13,
                 from ./zorp/zorp.h:34,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
/usr/include/zorp/zorplibconfig.h:176:0: note: this is the location of the previous definition
 #define PACKAGE_STRING ""

In file included from ./zorp/zorp.h:37:0,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
./zorp/zorpconfig.h:116:0: warning: "PACKAGE_TARNAME" redefined
 #define PACKAGE_TARNAME "zorp"

In file included from /usr/include/zorp/zorplib.h:23:0,
                 from /usr/include/zorp/misc.h:13,
                 from ./zorp/zorp.h:34,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
/usr/include/zorp/zorplibconfig.h:179:0: note: this is the location of the previous definition
 #define PACKAGE_TARNAME ""

In file included from ./zorp/zorp.h:37:0,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
./zorp/zorpconfig.h:122:0: warning: "PACKAGE_VERSION" redefined
 #define PACKAGE_VERSION "6.0.8"

In file included from /usr/include/zorp/zorplib.h:23:0,
                 from /usr/include/zorp/misc.h:13,
                 from ./zorp/zorp.h:34,
                 from ./zorp/pystruct.h:25,
                 from ./zorp/pyencryption.h:24,
                 from pyencryption.cc:21:
/usr/include/zorp/zorplibconfig.h:185:0: note: this is the location of the previous definition
 #define PACKAGE_VERSION ""

I'm quite sure, that this warnings are created because I changed the configure.in of the zorp to be able to compile it. In the original case the value are the same and the warning is not happen, but that not change the problem, just hide it.

I found two suggested solution for this:

1. Creating a new header.in file, which is filled in by the automake.
2. Using AX_PREFIX_CONFIG_H