ARROW-4697: [C++] Add URI parsing facility

[pitrou]

Using the uriparser C library.

[pitrou]

I can reproduce the manylinux1 failure locally but I don't understand what's happening. CMake does find out the full path to the uriparser library:

-- Added static library dependency uriparser_static: /tmp/build-PY3.7-32/uriparser_ep-install/lib/liburiparser.a

However, for some reason, the linker command then uses relative paths and fails:

c++: error: uriparser_ep-install/lib/liburiparser.a: No such file or directory

@xhochy @kszucs Any idea?

[pitrou]

MinGW build failure here. It seems the uriparser library doesn't build on MinGW:
https://ci.appveyor.com/project/pitrou/arrow/builds/22726490

I don't really know what to do with this.

@kou

[kou]

There is a build error in tool/uriparse.c:

https://ci.appveyor.com/project/kou/arrow#L387

C:/projects/arrow/cpp/build/uriparser_ep-prefix/src/uriparser_ep/tool/uriparse.c:47:39: error: conflicting types for 'inet_ntop'
 WINSOCK_API_LINKAGE const char WSAAPI inet_ntop(
                                       ^~~~~~~~~
In file included from C:/projects/arrow/cpp/build/uriparser_ep-prefix/src/uriparser_ep/tool/uriparse.c:45:
C:/msys64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:35: note: previous declaration of 'inet_ntop' was here
 WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR pStringBuf, size_t StringBufSize);
                                   ^~~~~~~~~
make[5]: *** [CMakeFiles/uriparse.dir/build.make:63: CMakeFiles/uriparse.dir/tool/uriparse.c.obj] Error 1
make[4]: *** [CMakeFiles/Makefile2:110: CMakeFiles/uriparse.dir/all] Error 2

It doesn't need to be built with -DURIPARSER_BUILD_TOOLS=OFF.
I sent a pull request to uriparser: uriparser/uriparser#56

[pitrou]

Good catch. Apparently URIPARSER_BUILD_TOOLS was ignored.

[hartwork]

Thanks to @kou for the pull request regarding URIPARSER_BUILD_TOOLS!

I welcome help understanding how to fix the build for MinGW before I time for an in-depth analysis myself. Making Travis or AppVeyor cover MinGW for uriparser is yet to be done as of today.

[hartwork]

PS: Existing commit uriparser/uriparser@8bdd07e and the existing prototype might be of interest.

[kou]

@hartwork Thanks for merging the pull request! I'll send another pull request for the build error.

@pitrou The pull request has been merged. Could you use the latest revision?

[pitrou]

@kou i'll be away until March 15th. There should be no urgency here, but otherwise another core developer could still push updates to this PR ;-)

[xhochy]

I can take of this PR once the CMake refactor is merged.

[pitrou]

I rebased on the latest CMake changes.
However there is a problem: by default, the CMake configuration tries to pull uriparser from Conda and fails. It looks like I have to pass -Duriparser_SOURCE=AUTO explicitly. This will not be practical: one has to add it to all CI and build scripts around. @xhochy What is your advice?

[pitrou]

The manylinux1 issue is still strinking, as described in #3779 (comment)

[pitrou]

Successful AppVeyor build here: https://ci.appveyor.com/project/pitrou/arrow/builds/23190635

[xhochy]

+1, LGTM