Re: Portability improvements with libbsd 0.3.0
On Sat, 2011-06-04 at 14:24:52 +0000, Thorsten Glaser wrote:
> Guillem Jover dixit:
> > pkg-config --cflags libbsd-overlay
>
> pkg-config is a GNU abomination and not used by BSD projects.
I disagree with the abomination part, but in any case do you have a
better alternative with equivalent functionality?
> >For existing packages using libbsd-dev (BCCed), several headers will
> >be removed in the upcoming 0.4.0 upstream release. To test that your
> >packages will keep building fine, you can temporarily define the
> >preprocessor macro LIBBSD_DISABLE_DEPRECATED, which will force the
> >build to fail, otherwise only warnings are emitted in some cases.
>
> Nice, that reduces the portability again… now we have to
> add code to handle different versions of libbsd.
There's two cases here:
One is the headers residing directly under /usr/include/, these were
causing issues, <nlist.h> conflicts with the libelf implementations,
<libutil.h> is a partial implementation and it has already made perl
pull libbsd unneedingly for its reverse build dependencies once, and
I don't think <vis.h> has caused issues, but just in case...
The other is headers that do not match the paths on the BSD systems,
so the premises here have been that if projects need to eventually
update to a newer libbsd version because they require new functions
from it, or are switching away from blundled implementations, then it
makes sense to remove deprecated headers anyway. That requiring a
newer libbsd unconditionally does not seem like such a big issue. And
finally to avoid unsuspecting developers starting to use them when
there's no need to.
I guess you are in a special place, as you seem to have integrated
libbsd directly in your upstream projects, instead of being just a
packaging patch. I've checked an seems like the only one using a
deprecated header is makefs (/usr/include/bsd/cdefs.h), if that's such
a big deal for you we can certainly talk about it, and I could delay
the removal, for example, or something else.
thanks,
guillem
Reply to: