[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Shared graphics libs & header file locations...



In message <[🔎] Pine.A32.3.91.960422150126.37688A-100000@corvus.ece.utexas.edu>, Guy Maor writes:
>Burning coals?  I've found libpbm incredibly useful.  I've had to
>generate pictures from code several times to illustrate things, and the
>p.m format is so trivial (raw with a short header).  They're really
>quite useful.  I'd be willing to generate this, or netpbm actually, as
>I think it has a few useful additions.

Well, the time I mucked with the source I was, uh, _unimpressed_ with
the configuration---I mean, I realize this was before autoconf and
metaconf were popular, but, jeez, did that build environment seem
primitive.  I was doing more sophisticated stuff with a little
mickey-mouse make on an Atari ST back when that was all being written.

For a while I thought about repackaging netpbm as newpbm or some such,
and learning all the neato config tools and the like, and maybe even
adding support for jpeg and png and anything else interesting.  Never
had the time, though I guess I might still do so one day.

>> >	libtiff (tiff)
>> This would need to be done fresh.  As I get the impression that it's
>> pretty stable, I'd be willing to do it.
>As I mentioned, I've already compiled a shared lib version for my own
>use.  Adding the debian files and uploading is a 30 minute job.

Sorry, I wasn't paying very close attention---it's been one of those
days; made the mistake of installing fvwm2, and spent half my day
getting tweaked, thereby leaving me not enough time to get my real
work done.

Anyway, I'll just say thanks, with an obligatory whine about don't
forget to put the soname in the package name and don't forget about
separating it into libgiffX and libtiffX-dev.

>There are probably about a dozen headers all together.  My suggestion
>of putting them all into a gr directory stems from a desire for
>compatibility with libgr, not for fear of header clutter.
>Source written for libgr would then compile only with a Makefile change
>(new library to link to), not changes to the code (changing '#include
><gr/pbm.h>' to '#include <pbm.h>').

Ah.  I didn't get sufficiently far into libgr to realize it had done
that---I just looked at the versions it included, looked at the most
recent upstream version I could find, and then threw my hands up and
started on zlib and libpng.

My only possible objection to this is that I know of a fair number of
programs _don't_ know about libgr, which is apparently a linux-ism.

Maybe we should have the postinsts for the various -dev files install
a symlink '. -> /usr/include/gr' if they don't find it?  That way most
programs will be able to behave sensibly?

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."


Reply to: