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

[Philip Prindeville]

  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.


>> 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.

It's not reasonable to expect that the libraries that your OS uses for stability and the libraries that you develop against are one in the same.

I want my development environment itself to be stable and robust and as bugfree as possible, but I don't mind developing software that uses bleeding edge libraries.

They are two entirely different things.