Fix gperf 3.1 linking errors

[Lastique]

This fixes linking errors with gperf 3.1. See #117 (comment).

• Fix const qualification mismatch with gperf-generated sources.

The hand-made struct declarations used non-const pointers while gperf sources an the generated sources declare these pointers as const-qualified. This doesn't cause the linking errors, but worth fixing nonetheless.

• Remove sources auto-generated by gperf.

This fixes linking errors when gperf 3.1 is used, introduced by #117. Hash function members use GPERF_SIZE_TYPE for size arguments, which is expanded to size_t and equivalent to unsigned long on x86-84. However, the old auto-generated sources committed in git use unsigned int, which causes linking errors when libresip.so is built.

By removing the sources we force them to be re-generated by the actual gperf in the system, which resolves the mismatch.

• Added the whole gen directory to .gitignore.

This prevents auto-generated sources from being committed to git.

[gjasny]

Is Windows generating these files as well or does it rely on the pre-generated ones?

[dpocock]

Is Windows generating these files as well or does it rely on the pre-generated ones?

When we build an official tarball or ZIP file for the reSIProcate download page, we use make dist and that includes copies of the files. They can be used as-is or regenerated if somebody tweaks one of them and uses make.

When people take the code directly from Github, either by cloning the repository or downloading one of the tarballs on Github's release page, they get the versions of the files committed in the repository.

You can find the logic related to this here:
https://github.com/resiprocate/resiprocate/blob/master/resip/stack/Makefile.am#L32

and BUILT_SOURCES is described here:
https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Using-BUILT_005fSOURCES

You can also see when they have last been changed:

git log resip/stack/gen

commit 3385e524c916ce6b7ea13b2de82d865334254e3c
Author: Daniel Pocock <daniel@pocock.pro>
Date:   Thu Sep 25 15:46:04 2014 +0200

    resip/stack/gen: re-run gperf

commit e515cacc51425b38ab57761d07a07302db1088a8
Author: Dario Bozzali <dario.bozzali@ifmgroup.it>
Date:   Wed Sep 24 18:04:33 2014 +0200

    Merge from master for gperf fixes

commit f71d4518fcb5b9a594d25fe9259e3f32a93a9241
Author: Dario Bozzali <dario.bozzali@ifmgroup.it>
Date:   Tue Sep 23 16:34:51 2014 +0200

    Merge from master after gperf-fixes

[sgodin]

When getting the source code from GIT.... Windows users rely on the pre-generated files, so that we don't require them to install the gperf tool to build. They can generate new files from gperf (if they add new headers or parameters), if they have it installed by using the gperf_w32.bat batch file. Scott

…

On Tue, Apr 16, 2019 at 4:28 PM Gregor Jasny ***@***.***> wrote: Is Windows generating these files as well or does it rely on the pre-generated ones? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACtNUaAxnBXSKS84aGXiPAXQCQKRJe1aks5vhjKHgaJpZM4cyJJY> .

[Lastique]

Configure scripts already check for gperf version to generate GPERF_SIZE_TYPE definition in config.h, so gperf is already a prerequisite for building. Isn't the same true when building on Windows? I can see Visual Studio projects and there's some gperf-related content in them as well.

[dpocock]

I've manually merged the first commit from this pull request, 30130a1, into master as it is essential for the build.

The other commit, removing the contents of the resip/stack/gen/* directory from the repository is a separate issue that we need to agree on for future releases so I leave the pull request open to discuss that.