Hi Quanah,
On Sat, 2 Nov 2019 at 03:32, Quanah Gibson-Mount wrote:
A few commits stacking up, so would like to review them for inclusion in an eventual 2.4.49.
Any chance that ITS#8996 could be included? Back in April, you said pkg-config support would need to wait for a 2.5 release [1], but given the pace of development, that could still be months or years away.
Thanks,
Hugh
[1] http://www.openldap.org/lists/openldap-devel/201904/msg00012.html
On Sat, 2 Nov 2019 at 11:02 pm, Hugh McMaster wrote:
Hi Quanah,
On Sat, 2 Nov 2019 at 03:32, Quanah Gibson-Mount wrote:
A few commits stacking up, so would like to review them for inclusion in
an
eventual 2.4.49.
Any chance that ITS#8996 could be included? Back in April, you said pkg-config support would need to wait for a 2.5 release [1], but given the pace of development, that could still be months or years away.
Thanks,
Hugh
[1] http://www.openldap.org/lists/openldap-devel/201904/msg00012.html
Just following up on this. I’m guessing it could be merged for RE25a? I’d prefer earlier but that’s outside my control.
Hugh
--On Friday, November 22, 2019 9:14 AM +1100 Hugh McMaster hugh.mcmaster@outlook.com wrote:
Any chance that ITS#8996 could be included? Back in April, you said pkg-config support would need to wait for a 2.5 release [1], but given the pace of development, that could still be months or years away.
Howard, what's your opinion/thought on adding this for master/RE25? Ryan tested it and it worked for him.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Friday, November 22, 2019 9:14 AM +1100 Hugh McMaster hugh.mcmaster@outlook.com wrote:
Any chance that ITS#8996 could be included? Back in April, you said pkg-config support would need to wait for a 2.5 release [1], but given the pace of development, that could still be months or years away.
Howard, what's your opinion/thought on adding this for master/RE25? Ryan tested it and it worked for him.
My personal opinion is that pkg-config is garbage and in all my experience it has only ever prevented me from building whatever I was working on at the time.
On Fri, 22 Nov 2019 at 21:59, Howard Chu wrote:
Quanah Gibson-Mount wrote:
Howard, what's your opinion/thought on adding this for master/RE25? Ryan tested it and it worked for him.
My personal opinion is that pkg-config is garbage and in all my experience it has only ever prevented me from building whatever I was working on at the time.
I get the feeling there's an interesting backstory here. I'm actually quite surprised you've had a bad experience with pkg-config. It's really quite useful and far easier than calling foo-config legacy scripts.
With regards to merging #8996, you didn't really answer Quanah's question. I'll also point out that you're not being forced to use openldap's pkg-config files.
Many people prefer pkg-config because of its simplicity in handling library dependencies and header inclusions. I'm simply trying to extend this simplicity to openldap.
Regards,
Hugh
Hugh McMaster wrote:
On Fri, 22 Nov 2019 at 21:59, Howard Chu wrote:
Quanah Gibson-Mount wrote:
Howard, what's your opinion/thought on adding this for master/RE25? Ryan tested it and it worked for him.
My personal opinion is that pkg-config is garbage and in all my experience it has only ever prevented me from building whatever I was working on at the time.
I get the feeling there's an interesting backstory here. I'm actually quite surprised you've had a bad experience with pkg-config. It's really quite useful and far easier than calling foo-config legacy scripts.
With regards to merging #8996, you didn't really answer Quanah's question. I'll also point out that you're not being forced to use openldap's pkg-config files.
Many people prefer pkg-config because of its simplicity in handling library dependencies and header inclusions. I'm simply trying to extend this simplicity to openldap.
AFAICS it is just another moving part that breaks. It doesn't provide any information. To use it you have to know whether to look in the /usr configs or /usr/local (or other places), If I know to look in /usr/local to find the package config I want, then I already know that the header and lib paths I need are in /usr/local and it hasn't helped at all.
More importantly, relying on it actively prevents you from working with packages in their own build directories. As someone who frequently has to build multiple versions of various dependencies to check that they all work with our OpenLDAP builds, I can't be bothered to re-install every different version I'm working with, particularly when I could otherwise just add a few items to LDFLAGS, LIBPATH, or whatnot. Every time I run across a build script that requires using pkg-config to find a package I have to go through and comment it out just so my env var settings will take effect.
So from an active developer's perspective, it adds steps but doesn't add useful information.
Hi Howard,
On Sun, 24 Nov 2019 at 01:59, Howard Chu wrote:
AFAICS it is just another moving part that breaks. It doesn't provide any information. To use it you have to know whether to look in the /usr configs or /usr/local (or other places),
pkg-config automatically knows where the headers and libraries are, since information is hard-coded into the pc file. If the headers and libraries are installed in a standard system location (e.g. /usr/lib or /usr/include), this information is not passed to the command line, since the paths are already in the environment.If you have pkg-config files in a custom location (e.g. /opt), you can simply set PKG_CONFIG_PATH and you'll get -L/opt/my/custom/path -ldap -lber
It's just a different workflow.
One of the problems with detecting openldap is that developers need to know where the libraries and headers are. pkg-config handles this for you when compiling. (And yes, I'll admit developers should know this anyway.) For instance, how many people know ldap depends on lber?
If I know to look in /usr/local to find the package config I want, then I already know that the header and lib paths I need are in /usr/local and it hasn't helped at all.
The point is that you had to know about your setup. pkg-config is just an easier way of working with headers and libraries. It also means I don't need to know which libraries depend on which others. It just works. OpenLDAP makes this harder than it should be.
More importantly, relying on it actively prevents you from working with packages in their own build directories. As someone who frequently has to build multiple versions of various dependencies to check that they all work with our OpenLDAP builds, I can't be bothered to re-install every different version I'm working with, particularly when I could otherwise just add a few items to LDFLAGS, LIBPATH, or whatnot. Every time I run across a build script that requires using pkg-config to find a package I have to go through and comment it out just so my env var settings will take effect.
PKG_CONFIG_PATH will help you here, but it's just one option. You could also use a (s)chroot or other containers.
So from an active developer's perspective, it adds steps but doesn't add useful information.
`pkg-config --libs ldap' or`pkg-config --cflags ldap' tells me everything I need to know to link against openldap.
If there is some particular information you need, we can also add custom variables.
One thing I'd like to reiterate is that you wouldn't be using these pkg-config files. They are for third parties. I believe there is a need for them -- and Ryan has expressed support after testing the patches. You seem to disagree about the need - that's fine. But I don't believe it's fair to prevent people from having the option to use pkg-config support if we can offer it.
Hugh
Hugh McMaster wrote:
Hi Howard,
On Sun, 24 Nov 2019 at 01:59, Howard Chu wrote:
AFAICS it is just another moving part that breaks. It doesn't provide any information. To use it you have to know whether to look in the /usr configs or /usr/local (or other places),
pkg-config automatically knows where the headers and libraries are, since information is hard-coded into the pc file. If the headers and libraries are installed in a standard system location (e.g. /usr/lib or /usr/include), this information is not passed to the command line, since the paths are already in the environment.If you have pkg-config files in a custom location (e.g. /opt), you can simply set PKG_CONFIG_PATH and you'll get -L/opt/my/custom/path -ldap -lber
It's just a different workflow.
One of the problems with detecting openldap is that developers need to know where the libraries and headers are. pkg-config handles this for you when compiling. (And yes, I'll admit developers should know this anyway.) For instance, how many people know ldap depends on lber?
If they're linking to shared libraries, they don't need to know, since libldap.so already links to liblber.so.
If we had a sane static library implementation, that included its dependency libraries in a __LIBS element (the same way ranlib stores symbol offsets in a __SYMDEF element in static libraries) then nobody would ever need to know. pkg-config is a bullshit hack that doesn't solve the root problem.
If I know to look in /usr/local to find the package config I want, then I already know that the header and lib paths I need are in /usr/local and it hasn't helped at all.
The point is that you had to know about your setup.
And pkg-config doesn't change that; I still have to know where the .pc files went.
But I don't believe it's fair to prevent people from having the option to use pkg-config support if we can offer it.
We have a project policy of not including content we can't support. And as a general circumstance, if we don't use something ourselves, then we aren't in a position to support it. Are you going to be here for the next 20+ years to support this addition?
On Sun, 24 Nov 2019 at 10:37 pm, Howard Chu wrote:
We have a project policy of not including content we can't support. And as a general circumstance, if we don't use something ourselves, then we aren't in a position to support it. Are you going to be here for the next 20+ years to support this addition?
If I have to be, yes.
That said, you clearly don’t believe pkg-config will benefit the project, and I respect that decision. I also respect (and appreciate) that you’ve gone into detail explaining your reasoning.
I won’t push this further here. Thanks for the debate.
Hugh
Hugh McMaster wrote:
PKG_CONFIG_PATH will help you here, but it's just one option. You could also use a (s)chroot or other containers.
When someone tells you they don't like something because it adds extra steps, suggesting *even more* additional steps is not a smart response.
So from an active developer's perspective, it adds steps but doesn't add useful information.
-
Howard Chu -
Hugh McMaster -
Quanah Gibson-Mount