[openldap] Add new port

Signed-off-by: Gordon Smith [email protected]

Add new port for OpenLDAP

• What does your PR fix?

  Fixes #18072

• Which triplets are supported/not supported? Have you updated the CI baseline?

  !windows Yes

• Does your PR follow the maintainer guide?

  Yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  Yes

If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

@dg0yt I had missed your last comments on my repo...

• I have now included your pkg-config for openssl changes
• I still need to run autoreconf when libtool version != 2.4.6 - so I added a cmake check for that specific case - at least its more obvious why its needed?
• No longer need the LIBS=-ldl in CentOS - is this because your pkg-config tweak effectivly resolves them?

Thx.

Note: I tweaked the configure parameters to remove all the warnings generated in buildtrees/openldap/config-x64-linux-dbg-err.log

https://github.com/microsoft/vcpkg/blob/52b66042533aaf7f5721941941fd12fbf46164d4/scripts/cmake/vcpkg_configure_make.cmake#L540-L558

• I still need to run autoreconf when libtool version != 2.4.6 - so I added a cmake check for that specific case - at least its more obvious why its needed?

I didn't say it isn't needed. I said repeatedly that passing AUTOCONFIG to vcpkg_configure_make will do just that: Run autoreconf before running configure.

• No longer need the LIBS=-ldl in CentOS - is this because your pkg-config tweak effectivly resolves them?

Probably yes: But that's what I already said in another comment. (I spent much time on fixing pc files.)

Unfortunately calling autoreconf -i on CentOS-7 will break the build, while autoreconf -f or autoreconf does not. And using AUTOCONFIG is not needed when libtool version == 2.4.6

Output log when using autoreconf -vfi option:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force 
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'.
libtoolize: copying file `build/ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'

Output log when using autoreconf -v option:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not running libtoolize: --install not given
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'

What kind of breakage happens with autoreconf -vfi? What about the proposal to add AC_CONFIG_MACRO_DIR([m4])?

That is what my very first PR did

@dy0yt - I added the m4 patch into the openssl.patch and suspect we have a winner!

I normally do that - but I thought the bots here didn't like that?

I normally do that - but I thought the bots here didn't like that?

There is only one relevant bot, checking that the git tree object referenced in versions does actually exist. It won't complain as long as you update versions (every time) after committing port changes. It is easy to miss this update after amending a PR :-)

@dg0yt Another tweak to fix OSX build - FYI the m4.patch won't work work with autoconf version >= 2.70 - looks like this ties in with libtool = 2.4.6 which doesn't need the m4 patch.

@dg0yt Can you confirm that you're happy? If I don't hear by tomorrow morning I will merge this.

Thanks!