On 09/03/13 11:48, Marc Lehmann wrote:
> On Sat, Mar 09, 2013 at 05:50:31AM +0100, Luca Barbato <lu_z...@gentoo.org>
> wrote:
>>> If "you" are gentoo and you add patches like that, potentially breaking
>>> compatibility with other distributions and upstream, then you are simply
>>> doing it wrong.
>>
>> Feel free to discuss about it here
>
> Why would I? It's not my job to educate gentoo. They can break programs
> and make life harder for its users as much as they want.
Had you spent enough time to follow the link you wouldn't have made an
ass out of yourself.
> And this is a good example on why the policy violation of the previous
> fedora libev maintainer causes problems now.
So all your ridiculous tirade boils down to you spouting sentences at
the wrong people.
libverto needs a pkg-config, it is either fixing libverto or add
something considered useful globally. The maintainer for the libverto
ebuild asked for the pkg-config file and the maintainer for the libev
ebuild, not knowing you are difficult about it, assumed that libev would
add the pkg-config in the future, thus accepted.
ALL WRITTEN ON THE ISSUE I POINTED YOU.
HAD YOU BEEN SANE YOU WOULD HAD JUST SIMPLY SAID "no, libev will not
support that upstream" IN THE BUG GENTOO WOULD HAD REVERTED AND FIXED
libverto ALREADY.
We have a quite stated policy that we try to follow upstream the best we
can. Your delusional nonsense is just annoying the hell of me.
> This is an unfounded claim. Repeating it will not make it true.
True for me and my users.
I'm upstream for some software *vaguely* more spread and used than a
good event loop library...
>> In order to get the same features I had to rely on non-standard
>> AX_CHECK_LIBRARY and luckily I'm not using alternative build systems.
>
> I am sorry, but I think you are making this up. If you disagree, please
> explain why you _had_ to rely on "non-standard AX_CHECK_LIBRARY".
You use autotools, assuming you know what you use.
AC_CHECK_LIBRARY extends the library checks so you can have, as in
pkg-config PKG_CHECK_MODULES and extensions, namespaced CFLAGS and LIBS
override for the specific check.
AX_CHECK_LIBRARY([LIBEV], [ev.h], [ev], [],
[AC_MSG_ERROR([libev not found, feng requires libev])])
or
PKG_CHECK_MODULES([LIBEV], [libev])
This let you override the search paths using LIBEV_CFLAGS and LIBEV_LIBS.
> You can specify the nonstandard location of libev to a configure script
> that doesn't even mention libev in any way, and it will just work. That's
> zero overhead.
Please bake an example using standard autotools.
>> So for the normal autotool situation you spare lines in your configure,
>> have a clear and clean way to override the library and headers paths
>> with the right granularity and if you have a decent cross environment
>> and a decent pkg-config your life gets quite simpler.
>
> Exactly, in the normal case, this is true. pkg-config would not help here
> at all, it would only increase the complexity of the configure script.
The vanilla autotools way would be a check for the library and a check
for the header.
AC_CHECK_HEADERS_ONCE([ev.h])
AC_SEARCH_LIBS([somefunc],[libev],[],
[AC_MSG_ERROR([libev not found, feng requires libev])])
or equivalent as in
AC_CHECK_HEADER([libev],
[AC_CHECK_LIB([ev.h],[...],[...])],
[...], [...])
Plus the LIBS and CFLAGS variables save and restore stuff using
AC_ARG_VAR, AC_CACHE_VAL.
Your attitude towards people is really aggravating.
I notified the interested party in Gentoo to undo the patch and fix
libverto meanwhile.
lu
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
