patch: configure rm libpng version tests
It seems that libpng is up to 1.5.0 now, so it's time to rip out some version tests.
Joerg wrote:
On Wed, Jan 26, 2011 at 02:42:19AM +0000, corvid wrote:
It seems that libpng is up to 1.5.0 now, so it's time to rip out some version tests.
libpng 1.5.0 also creates a lot of fallout, so expect users to stay with 1.4 for a while...
In that people don't like the changes hiding data structures, or that it will take time before developers get their software sorted out to handle it? Is there a good reason not to use whatever libpng-config is linked to? I like the idea of not having to touch configure.in every time there's a new minor version, especially given how long we go between releases.
On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote:
Joerg wrote:
On Wed, Jan 26, 2011 at 02:42:19AM +0000, corvid wrote:
It seems that libpng is up to 1.5.0 now, so it's time to rip out some version tests.
libpng 1.5.0 also creates a lot of fallout, so expect users to stay with 1.4 for a while...
In that people don't like the changes hiding data structures, or that it will take time before developers get their software sorted out to handle it?
A lot of software was broken by it and it will take time to sort that out.
Is there a good reason not to use whatever libpng-config is linked to? I like the idea of not having to touch configure.in every time there's a new minor version, especially given how long we go between releases.
As long as the libpng-config can be overriden by environment / configure argument and the name of the variable is documented, that's fine. Joerg
Joerg wrote:
On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote:
Is there a good reason not to use whatever libpng-config is linked to? I like the idea of not having to touch configure.in every time there's a new minor version, especially given how long we go between releases.
As long as the libpng-config can be overriden by environment / configure argument and the name of the variable is documented, that's fine.
There is a $PNG_CONFIG in there. Hmm, a quick attempt to look through the autoconf manual doesn't say anything about how to tell --help to list env variables. What is generally done?
Joerg wrote:
On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote:
Joerg wrote:
On Wed, Jan 26, 2011 at 02:42:19AM +0000, corvid wrote:
It seems that libpng is up to 1.5.0 now, so it's time to rip out some version tests.
libpng 1.5.0 also creates a lot of fallout, so expect users to stay with 1.4 for a while...
In that people don't like the changes hiding data structures, or that it will take time before developers get their software sorted out to handle it?
A lot of software was broken by it and it will take time to sort that out.
Can we continue to ignore 1.5.x safely? I live in a Slackware bubble and don't pay attention to what the other distributions are up to.
On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote:
[...] Is there a good reason not to use whatever libpng-config is linked to?
I don't know these days, but a few years ago I had to add all of those tests because of different names of the configure script and there were distros packing two versions of the library and using the script name to differentitate among them. *Handle with care* -- Cheers Jorge.-
Jorge wrote:
On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote:
[...] Is there a good reason not to use whatever libpng-config is linked to?
I don't know these days, but a few years ago I had to add all of those tests because of different names of the configure script and there were distros packing two versions of the library and using the script name to differentitate among them.
*Handle with care*
Okay, how about rearranging to put libpng-config first to get whatever they prefer, and we can add in backup tests for versions with less... I was going to say 'urgency', but of course we haven't released a version that handles 1.4 yet... (Aside: With eleven years of history now, we seem to run into a lot of "I think a long time ago, we needed that for something" which suggests that we should be a bit obsessive about our documentation. Sometimes you can get a hint from the list archives, but often the pattern is "A release looms, and someone contacts Jorge off-list about whatever problem, and it is quietly patched".)
* corvid <corvid@lavabit.com> schrieb:
+ PNG_CONFIG=`which libpng-config` fi
Why not just using pkg-config ? (which would be _much_ more distmaintainer/packager-friendly) PKG_CHECK_MODULE([...]) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
Enrico wrote:
* corvid <corvid@lavabit.com> schrieb:
+ PNG_CONFIG=`which libpng-config` fi
Why not just using pkg-config ? (which would be _much_ more distmaintainer/packager-friendly)
PKG_CHECK_MODULE([...])
Is pkg-config ubiquitous where we aren't adding to dependencies too much? I guess I like to imagine dillo in the hands of someone like me who is not a maintainer/packager and might have weird/old/underpowered hardware and have limited patience for finding/downloading/compiling even more stuff in order to find out whether I even like dillo.
On Sat, Jan 29, 2011 at 08:38:50PM +0000, corvid wrote:
Enrico wrote:
* corvid <corvid@lavabit.com> schrieb:
+ PNG_CONFIG=`which libpng-config` fi
Why not just using pkg-config ? (which would be _much_ more distmaintainer/packager-friendly)
Because most of the original libpng-config is older than the pkgconfig support in libpng :)
PKG_CHECK_MODULE([...])
Is pkg-config ubiquitous where we aren't adding to dependencies too much?
Pretty much. If you don't have it, you can still override the automatic detection via PNG_CFLAGS / PNG_LIBS or so. Joerg
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
Because most of the original libpng-config is older than the pkgconfig support in libpng :)
Be prepared that it gets dropped some day. (some distros maybe already removed it already). And keep in mind that these *-config scripts are quite crosscompile-unfriedly.
Pretty much. If you don't have it, you can still override the automatic detection via PNG_CFLAGS / PNG_LIBS or so.
Which requires another special tweak in the distro's package build rules/descriptors - exactly what packagers do not like. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote:
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
Because most of the original libpng-config is older than the pkgconfig support in libpng :)
Be prepared that it gets dropped some day. (some distros maybe already removed it already). And keep in mind that these *-config scripts are quite crosscompile-unfriedly.
Well, as long as upstream installs it...
Pretty much. If you don't have it, you can still override the automatic detection via PNG_CFLAGS / PNG_LIBS or so.
Which requires another special tweak in the distro's package build rules/descriptors - exactly what packagers do not like.
Packagers should provide pkg-config. The only situation in which the manual override is needed if you want to build it on a system that doesn't have pkg-config and where you don't want to install it. Joerg
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote:
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
Because most of the original libpng-config is older than the pkgconfig support in libpng :)
Be prepared that it gets dropped some day. (some distros maybe already removed it already). And keep in mind that these *-config scripts are quite crosscompile-unfriedly.
Well, as long as upstream installs it...
Lets see, how long ...
Pretty much. If you don't have it, you can still override the automatic detection via PNG_CFLAGS / PNG_LIBS or so.
Which requires another special tweak in the distro's package build rules/descriptors - exactly what packagers do not like.
Packagers should provide pkg-config.
No, upstream should do that (packagers should not have to touch any area of the sourcecode). And importing packages should _use_ it. (instead of old legacy cruft like the -config scripts or esoteric autofool macros).
The only situation in which the manual override is needed if you want to build it on a system that doesn't have pkg-config and where you don't want to install it.
Why should some refuse to install such an fundamental tool ? cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
On Mon, Jan 31, 2011 at 01:21:36AM +0100, Enrico Weigelt wrote:
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote:
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
Pretty much. If you don't have it, you can still override the automatic detection via PNG_CFLAGS / PNG_LIBS or so.
Which requires another special tweak in the distro's package build rules/descriptors - exactly what packagers do not like.
Packagers should provide pkg-config.
No, upstream should do that (packagers should not have to touch any area of the sourcecode). And importing packages should _use_ it. (instead of old legacy cruft like the -config scripts or esoteric autofool macros).
You are misunderstanding what I say. Packagers should depend on pkg-config. If they don't, they are responsible for doing it by hand.
The only situation in which the manual override is needed if you want to build it on a system that doesn't have pkg-config and where you don't want to install it.
Why should some refuse to install such an fundamental tool ?
Have you ever looked at the pkg-config source? For something as fundamental as pkg-config, the source code is a mess. It has a local copy of at least half of glib1 for example... Joerg
* Joerg Sonnenberger <joerg.sonnenberger@web.de> schrieb:
No, upstream should do that (packagers should not have to touch any area of the sourcecode). And importing packages should _use_ it. (instead of old legacy cruft like the -config scripts or esoteric autofool macros).
You are misunderstanding what I say. Packagers should depend on pkg-config. If they don't, they are responsible for doing it by hand.
To make it a bit more clear: packagers (those folks who create the packages for certain distros) should (be able to) rely on the individual upstreams properly using the pkg-config infrastructure, so they have one common place for doing their necessary adaptions.
Why should some refuse to install such an fundamental tool ?
Have you ever looked at the pkg-config source? For something as fundamental as pkg-config, the source code is a mess. It has a local copy of at least half of glib1 for example...
Yes, I've worked on the codebase. It's not nice, but at least it works (probably better than it will after the already discussed transition to glib2 ;-p). Patches are always welcomed ;-) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
joerg.sonnenberger＠web.de -
weigelt＠metux.de