Re: [9fans] Announce: standalone libixp

[Enrico Weigelt <weigelt@metux.de>]

* Kris Maglione <bsdaemon@comcast.net> wrote:
> On Sat, Jun 30, 2007 at 05:38:14PM +0200, Enrico Weigelt wrote:
> >I've just finished my standlone libixp package (forked from wmii).
>
> There's no need to 'fork' it from wmii, it's always been
> available standalone, the latest snapshot just happens to be
> distributed with wmii.

Ah, didn't know of that.
I just took it from wmii and changed it to my needs.

> >It's an completely standalone package with no deps (beside libc),
> >provides pkg-config descriptor and shared library. Include files
> >are installed in their own subdir ($INCLUDEDIR/9p-ixp).
>
> I really see no need to create a separate include directory.
> There are only 2 include files, ixp.h and ixp_fcall.h (the 3 new
> ones for the threading stubs don't count. There's really no need
> for them).

I want to keep things clean and reduce pollution of /usr/include.

> I really don't see the need for pkg-config either. It's designed
> for libraries that are so insanely complex that you need helpers
> just to build or link against them:

pkg-config is an easy to use database to check for libs and get
the right flags and pathes. If evryone would use it, builds would
be much, much easier. Esoteric "tests" (like they're common in
autoconf world) are not needed anymore. Simply query pkg-config.

Especially if you don't have evrything in standard locations
(ie. on crosscompiling), there's no need for laying hands on
individual packages - just tweak pkg-config *once*.

> %pkg-config --cflags --libs gnome
> -DNEED_GNOMESUPPORT_H -I/usr/local/include/gnome-1.0 -I/usr/local/include
> -I/usr/local/lib/gnome-libs/include -I/usr/local/include/gtk12
> -I/usr/local/include/glib12 -I/usr/X11R6/include  -L/usr/local/lib -lgnome
> -lgnomesupport -lintl -lesd -laudiofile -lm -lglib-12

I don't see what's the problem here. It's very easy to use.

> As for the shared object, I just don't see the point. If you
> provide it as a shared object, then people will use the shared
> object rather than statically linking it.

Don't you want people the freedom to choose what they like best ?

There are valid reasons for using shared libraries, ie. not the
need to rebuild applications on library update or saving resources.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------