Re: [PATCH 1/2] configure: add a fallback check for zlib
Fraser Tweedale wrote: On Sat, May 10, 2014 at 05:27:34PM -0500, Felipe Contreras wrote: Tomi Ollila wrote: On Sun, May 11 2014, Felipe Contreras felipe.contre...@gmail.com wrote: Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. But for that we'd need to figure out the version, and is there simpler robust way to do that some other way ? I don't meant to change the code that is checking for the version in the patch, you use the same code, but instead of have_zlib.c gen_zlib_pc.c, or something. [please cc me in replies; I am not subscribed to the list] Unless the list does Reply-To munging, there's no need to say that. And this is a sane list, so no Reply-To munging :) http://felipec.wordpress.com/2010/08/03/avoid-reply-to-munging-mail-as-mail-was-meant-to-be/ -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] configure: add a fallback check for zlib
On Sat, May 10, 2014 at 05:27:34PM -0500, Felipe Contreras wrote: Tomi Ollila wrote: On Sun, May 11 2014, Felipe Contreras felipe.contre...@gmail.com wrote: Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. But for that we'd need to figure out the version, and is there simpler robust way to do that some other way ? I don't meant to change the code that is checking for the version in the patch, you use the same code, but instead of have_zlib.c gen_zlib_pc.c, or something. [please cc me in replies; I am not subscribed to the list] I think that the additional complexity outweighs the benefit of a somewhat cleaner build script. If the $vz1, $vz2, et al. are what's bothering you, perhaps we could push the complexity of version comparison into have_zlib.c and supply the (string) version number as an argument to the program. The have_zlib program could do the comparison and exit accordingly, and plain old 1.2.5.2 can take its place in the configure script once more. However, I don't see any problems with the patch as it is; I have tested it on FreeBSD 10.0 and it works. Regards, Fraser -- Felipe Contreras pgpnzNNymOoxA.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] configure: add a fallback check for zlib
On Wed, May 21 2014, Fraser Tweedale fr...@frase.id.au wrote: On Sat, May 10, 2014 at 05:27:34PM -0500, Felipe Contreras wrote: Tomi Ollila wrote: On Sun, May 11 2014, Felipe Contreras felipe.contre...@gmail.com wrote: Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. But for that we'd need to figure out the version, and is there simpler robust way to do that some other way ? I don't meant to change the code that is checking for the version in the patch, you use the same code, but instead of have_zlib.c gen_zlib_pc.c, or something. [please cc me in replies; I am not subscribed to the list] I think that the additional complexity outweighs the benefit of a somewhat cleaner build script. If the $vz1, $vz2, et al. are what's bothering you, perhaps we could push the complexity of version comparison into have_zlib.c and supply the (string) version number as an argument to the program. The have_zlib program could do the comparison and exit accordingly, and plain old 1.2.5.2 can take its place in the configure script once more. However, I don't see any problems with the patch as it is; I have tested it on FreeBSD 10.0 and it works. Did you notice http://mid.gmane.org/1399864172-28227-1-git-send-email-felipe.contre...@gmail.com :D Regards, Fraser -- Felipe Contreras Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] configure: add a fallback check for zlib
On Wed, May 21, 2014 at 10:34:25PM +0300, Tomi Ollila wrote: On Wed, May 21 2014, Fraser Tweedale fr...@frase.id.au wrote: On Sat, May 10, 2014 at 05:27:34PM -0500, Felipe Contreras wrote: Tomi Ollila wrote: On Sun, May 11 2014, Felipe Contreras felipe.contre...@gmail.com wrote: Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. But for that we'd need to figure out the version, and is there simpler robust way to do that some other way ? I don't meant to change the code that is checking for the version in the patch, you use the same code, but instead of have_zlib.c gen_zlib_pc.c, or something. [please cc me in replies; I am not subscribed to the list] I think that the additional complexity outweighs the benefit of a somewhat cleaner build script. If the $vz1, $vz2, et al. are what's bothering you, perhaps we could push the complexity of version comparison into have_zlib.c and supply the (string) version number as an argument to the program. The have_zlib program could do the comparison and exit accordingly, and plain old 1.2.5.2 can take its place in the configure script once more. However, I don't see any problems with the patch as it is; I have tested it on FreeBSD 10.0 and it works. Did you notice http://mid.gmane.org/1399864172-28227-1-git-send-email-felipe.contre...@gmail.com :D Whups, I missed that one :) Cheers. Regards, Fraser -- Felipe Contreras Tomi pgpJyZ9LmgQ9K.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 1/2] configure: add a fallback check for zlib
Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 1/2] configure: add a fallback check for zlib
On Sun, May 11 2014, Felipe Contreras felipe.contre...@gmail.com wrote: Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. But for that we'd need to figure out the version, and is there simpler robust way to do that some other way ? Xīcò: zv4=2 instead of zv4=1 (1.2.5.2) -- Felipe Contreras Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 1/2] configure: add a fallback check for zlib
Tomi Ollila wrote: On Sun, May 11 2014, Felipe Contreras felipe.contre...@gmail.com wrote: Xīcò wrote: Since zlib is part of the base system, FreeBSD chose not to register it in pkg-config through zlib.pc. As a fallback test, configure will build and run a zlib version check and make sure the header and library versions are compatible. We could try to generate our on zlib.pc, this way the configure script would be cleaner. But for that we'd need to figure out the version, and is there simpler robust way to do that some other way ? I don't meant to change the code that is checking for the version in the patch, you use the same code, but instead of have_zlib.c gen_zlib_pc.c, or something. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch