[asterisk-dev] Still running into build issues w/ trunk, bug 17720

[Kevin P. Fleming]

On 07/29/2010 02:14 PM, Philip Prindeville wrote:
>   On 7/29/10 11:38 AM, Kevin P. Fleming wrote:
>> On 07/29/2010 01:27 PM, Philip Prindeville wrote:
>>>    Filed this bug:
>>>
>>> https://issues.asterisk.org/view.php?id=17720
>>>
>>> In short, the current autoconf setup doesn't allow you to manually specify values (like PGSQL_INCLUDE) as parameters to ./configure...  It detects pg-config and grabs everything from there.
>> It's never going to allow you to specify PGSQL_INCLUDE. The configure
>> script relies on pg-config providing the correct values to be used, so
>> the only input you have into the process is telling the configure script
>> where pg-config can be found (or which version should be used).
> 
> Why not allow the user as much granularity of control as he wants?
> 
> If he specifies the path explicitly, then pg-config isn't even needed.

Yes, it is. pg-config (as do all pkg-config-based tools) have the
ability to provide much more information than just the location of the
relevant header files and libraries. We don't want that information
embedded in the configure script if it's not necessary, because it will
just go out of date and cause build problems. For many libraries we have
no choice, but for some libraries where the library provider gives us a
tool to learn what we need, we absolutely want to use that tool to get
the information.

For a user who wants to override what the configure script does, there
is a method already available: edit the makeopts file that is generated
to make PGSQL_INCLUDE and PGSQL_LIB point have whatever contents you
like. It's not in our best interests to attempt to build a configure
script that can accommodate any possible usage model, no matter how
complex. The configure script is a helper, and everything that it does
can already be done via other means, so for those complex scenarios the
'helper' will not be of as much use as it could be.

> 
> 
>>> This is both a problem when cross-building, and when you have a private local library build of Postgres that you want to link and test against... and you don't want it seeing the host headers/libraries.
>>>
>>> This also affects more than just Postgres, it's a repeat of the issue we were seeing with netsnmp in 16991.
>>>
>>> Do we want to fix this in 1.8?
>>>
>>> And do we want to fix this piecemeal, or overhaul the autoconf stuff and scrub it clean in one go?
>>>
>>> I'd rather put this puppy to bed, because it keeps coming up in multiple manifestations, but it's not my call of course.
>> It should be fixed, if the correct version of pg-config is being called
>> but the output of that tool is not being properly utilized in the build
>> process. If there is no correct version of pg-config, or the version
>> that is pointed to does not produce the correct output, then the failure
>> is in the system installation, not in Asterisk's configure script.
>>
> 
> Here we disagree.
> 
> If I've installed postgres on my system and it works for all of the utilities on my system that use postgres, but I've got a new version of postgres that's pre-release and I want to develop a new asterisk feature simultaneously that leverages that new functionality in postgres, I should be able to.
> 
> Otherwise, if we do what you propose, then I'd have to wait until the new version of postgres was released as the standard version for (say) Fedora or Ubuntu, install that... and then develop for it.  Which could take months.

That is not at all what I proposed. When you make inflammatory,
over-the-top statements based on a misinterpretation of the answers to
your questions, it does not make people want to continue helping you...
and you have exhibited a pattern of doing just this.

What I said was if you have installed a different version of postgres on
your system (in any place you care to install it), that installation
will include a pg-config tool (unless you've done something to stop that
from happening). That pg-config tool is what the configure script will
consult to learn how to compile against and link to the libraries
provided by that installation of postgres. If telling the configure
script where that pg-config tool lives does not produce a build that
actually uses that installation of postgres, then that is a bug...
assuming that the pg-config tool in that location works properly and
reports the proper information.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org