Re: [Tigervnc-devel] GNU TLS

2010-05-13 Thread DRC
Works great! Thanks! On 5/13/10 8:46 AM, Adam Tkac wrote: > On Fri, May 07, 2010 at 11:35:44AM -0500, DRC wrote: >> Adam, >> >> My vote would be to go ahead and make these modifications, unless anyone >> strongly objects. > > Commited as r4053. > > Regards, Adam >

Re: [Tigervnc-devel] GNU TLS

2010-05-13 Thread Adam Tkac
On Fri, May 07, 2010 at 11:35:44AM -0500, DRC wrote: > Adam, > > My vote would be to go ahead and make these modifications, unless anyone > strongly objects. Commited as r4053. Regards, Adam -- Adam Tkac, Red Hat, Inc. --

Re: [Tigervnc-devel] GNU TLS

2010-05-07 Thread DRC
Adam, My vote would be to go ahead and make these modifications, unless anyone strongly objects. > Yes, we can abandon PKG_CHECK_MODULES macro and use AC_CHECK_LIB > instead. It might be bigger as Pierre said but it will be far more > compatible. I think that AC_CHECK_LIB is sufficient, no > AC_C

Re: [Tigervnc-devel] GNU TLS

2010-05-03 Thread Adam Tkac
On Wed, Apr 28, 2010 at 06:25:51PM -0500, DRC wrote: > Additional fuel for this discussion-- the Windows build now fails as > well unless you specify "configure --disable-gnutls". Thanks for report. Should be fixed in r4051. > On 4/28/10 2:53 PM, DRC wrote: > > There are a couple of problems with

Re: [Tigervnc-devel] GNU TLS

2010-05-03 Thread Adam Tkac
On Wed, Apr 28, 2010 at 02:53:10PM -0500, DRC wrote: > There are a couple of problems with this, as I see it: Hello all, I read the whole thread, read my opinions below. > 1) GNU TLS support is enabled by default, so if GNU TLS isn't installed > on the system (which is the case for non-Linux sys

Re: [Tigervnc-devel] GNU TLS

2010-04-29 Thread DRC
I was able to get it to work by using autotools from MacPorts, e.g.: PATH=/opt/local/bin:$PATH autoreconf -fiv This version has pkg-config and the correct macros. I disagree, in general, with the philosophy that users should develop against the tarball rather than SVN. However, I really don't h

Re: [Tigervnc-devel] GNU TLS

2010-04-29 Thread Pierre Ossman
On Thu, 29 Apr 2010 02:33:24 -0500 DRC wrote: > OK, well, if PKG_CHECK_MODULES is going to be used, then I strongly > believe that we should: > > (a) not enable GNU TLS support by default. Otherwise, whenever someone > tries to build on Windows or Mac or any other platform that doesn't have > G

Re: [Tigervnc-devel] GNU TLS

2010-04-29 Thread DRC
OK, well, if PKG_CHECK_MODULES is going to be used, then I strongly believe that we should: (a) not enable GNU TLS support by default. Otherwise, whenever someone tries to build on Windows or Mac or any other platform that doesn't have GNU TLS, the build will fail. (b) include the PKG_CHECK_MODU

Re: [Tigervnc-devel] GNU TLS

2010-04-29 Thread Alan Coopersmith
Pierre Ossman wrote: >> -- A local version of PKG_CHECK_MODULES should be included in our build >> for use on systems that do not provide it. > > Sure, if it can be done cleanly. It would only be needed for developers building from raw svn checkout on machines they haven't installed pkg-config on

Re: [Tigervnc-devel] GNU TLS

2010-04-29 Thread Pierre Ossman
On Wed, 28 Apr 2010 14:53:10 -0500 DRC wrote: > > I believe that the behavior should be as follows: > > -- A mechanism other than PKG_CHECK_MODULES should be used to detect the > presence of GNU TLS (AC_CHECK_LIB or AC_CHECK_HEADER, probably.) > NAK. pkg-config is a lot smarter than AC_CHECK_

Re: [Tigervnc-devel] GNU TLS

2010-04-28 Thread DRC
Additional fuel for this discussion-- the Windows build now fails as well unless you specify "configure --disable-gnutls". On 4/28/10 2:53 PM, DRC wrote: > There are a couple of problems with this, as I see it: > > 1) GNU TLS support is enabled by default, so if GNU TLS isn't installed > on the s

[Tigervnc-devel] GNU TLS

2010-04-28 Thread DRC
There are a couple of problems with this, as I see it: 1) GNU TLS support is enabled by default, so if GNU TLS isn't installed on the system (which is the case for non-Linux systems, generally), then configure fails. Our build should not require GNU TLS, nor should it require that the user explic