Skip site navigation (1) Skip section navigation (2)

Re: configure.in / xml / quoting trouble

From: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: configure.in / xml / quoting trouble
Date: 2007-07-20 17:32:39
Message-ID: 20070720173239.GO17088@quartz.itdept.newn.cam.ac.uk (view raw or flat)
Thread:
Lists: pgsql-patches
On Fri, Jul 20, 2007 at 09:37:15AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Am Freitag, 20. Juli 2007 13:28 schrieb Patrick Welche:
> >> Also, why did postgresql choose not to use automake?
> 
> > The was never such a choice made.
>
> According to the archives, it was brought up a couple times around the
> 1999-2000 time frame, but no one ever made a case that it'd be worth the
> pain of changing over.  At the time, we had subprojects in the tree with
> their own configure/build systems (odbc, libpqxx) and I think
> automake-ification was considered a way to try to clean that situation
> up.  But now it's been resolved by kicking the subprojects out again,
> and so I don't really see that automake has much to offer us.

OK - I was just playing with that libxml2 problem with a test
project, and somehow the linking went correctly and used the right
flags. It seems (not tested to the extremes) that I just got "do
the right thing with libxml2.la" for free (i.e., use libtool --mode=link)
just by having used automake. (I'll look at that a bit more to make
sure.)

Also, what was the danger with linking pthread? (I do see a
  --with-threads          add multithread support(on)
switch to turn it off in libxml2)

Cheers,

Patrick

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-07-20 17:59:38
Subject: Re: configure.in / xml / quoting trouble
Previous:From: Tom LaneDate: 2007-07-20 16:47:35
Subject: Re: SSPI authentication - patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group