[Cairo] make error with cvs cairo

[Carl Worth]

On Sep 15, Bill Spitzak wrote:
 > On Monday 15 September 2003 12:46 pm, Carl Worth wrote:
 > >
 > > Patches would be gratefully accepted to improve the portability of
 > > Cairo with respect to this and other problems.
 > 
 > I have tried to do this several times now, but have been continuously 
 > frustrated and have to revert back to the CVS code.

I'm sorry you haven't succeeded in making Cairo more portable. Others
have been making quite a bit of progress and we'll get there
eventually. You'll see below that several of the problems you hit in
the past have been addressed in the current code base.

I should point out that in addition to patches, problem reports are
also well received. I can't fix problems I'm not aware of, (and as you
might imagine, Cairo builds without any problem on my system).

Also, Cairo is still very much an experimental code base. It may
depend on newer versions of libraries than are available in some
distributions. Users of Cairo today are expected to be able to obtain
the newer versions. Otherwise, potential users can wait until all of
this stuff stabilizes and appears in a pre-packaged form.

Finally, Cairo is still evolving. It originally depended strictly on
the Xrender library and a server with the Render extension. It now has
a separate backend to draw to an in-memory image, but there's still
work to be done to enable the backends to be compiled conditionally.

 > I strongly recommend that Cairo eliminate ALL other header files that are not 
 > on a plain POSIX system from it's headers.

Cairo's public headers will continue to include header files for
libraries on which Cairo depends. For example, the main header file
will likely always include "ic.h", (or whatever we end up renaming the
libic library that provide the in-memory image backend for Cairo).

 > This means no Xlib or Xrender or freetype.

I do plan to move backend-specific functionality, (eg. X11/Render,
etc.), to their own header files, (eg. cairo-x11.h). But, until we fix
Cairo so that the different backends can be compiled conditionally,
simply splitting the public header file won't make it any easier to
compile Cairo itself.

 > And get rid of typedefs like CairoDouble

There has never been a typedef for CairoDouble nor anything like
it. The only typedefs provided by the public header files are for
opaque struct "objects" and enum values. (More on internal typedefs
below).

 > However it is unclear if any work I did along these lines would be
 > accepted.

I would be grateful to receive patches from anyone that helped
increase the portability of Cairo.

 > Attached is notes I made from my most recent attempts to get Cairo compiled 
 > on a RedHat 2.4.18 machine, without root access, so you can see just how 
 > frustrating this is.

Thanks for the notes. Problem reports like this can be very
helpful. Many of the Cairo-related problems below have already been
dealt with in the current source tree.

 > I *really* want to help with Cairo but the current design is
 > preventing this:

Great! Please update, try again, and let us know where the problems
remain. If its possible for you to provide patches to address the
problems, that's even better, (obviously).

 > slim autogen.sh ran the "1.4" version of programs like automake. I
 > typed the commands by hand without that version number.

Mateusz Loskot reported this problem to me on August 18. I committed a
fix the next day:

	revision 1.2
	date: 2003/08/19 01:54:21;  author: cworth;  state: Exp;  lines: +2 -2
	Remove explicit versions from aclocal and automake,
	(I don't think slim is all that particular when it comes to the
	autotools).

 > I set it first to a directory that started from an NFS mounted remote
 > drive. Then "make install" did not work because mkdir screwed up
 > trying to create the directory, giving me an error that it could not
 > create the root directory name.

Is there a bug here to be filed against one of the autotools?

 > It complained about slim. Said PKG_CONFIG_PATH had to be set, so I set
 > it to prefix. Still compained, so I figured out it had to be set to
 > local/lib/pkgconfig. It really ought to try the prefix!

I'm sure the pkgconfig maintainers would be glad to accept a patch if
you have an idea for improving it.

 > ./autogen produced compaint: checking whether build environment is
 > sane... configure: error: newly created file is older than distributed
 > files!  Check your system clock

NFS + compilation => pain

 > make in Cairo now quit at cairo.h complaining about
 > PictStandardARGB32 and many other symbols were undefined.
 > Commented out those symbols.

See recent discussion on the Cairo mailing list. As soon as the
problem was reported I committed a fix that will direct users to
obtain a new Xrender installation if needed. (And I also suggested
that the long term solution would be to fix Cairo so that it could be
compiled without the Xrender backend if desired).

 > Now it quit on XFixed. Copied that (this REALLY should be int!!!)

This is now cairo_fixed_16_16_t or cairo_fixed_t. The typedef here is
for internal use by Cairo. It is quite helpful as there is lots of
fixed-point arithmetic here of various sizes, (cairo_fixed_32_32_t
also shows up). And fixed-point arithmetic is not equivalent to
integer arithmetic. I find the typedefs quite helpful as I maintain
the code.

 > Now it went quite awhile and quit in cairo_path_scroke, complaining
 > about XDouble. Copied that as well.

Fixed.

 > Then it was XPointDouble. Copied that.

Fixed.

 > Then it quit on PictStandardA8 agian, in cairo_surface. This time I
 > decided to copy those symbols from the Xrender header file.

See above.

 > Then it quit on XTrapezoid. Which required XLineFixed, and that
 > required XPointFixed.

Fixed.

 > No configure program. So I just tried make. It immediatly complained
 > about Package xft. and PKG_CONFIG_PATH.

Yup. Cairo currently does depend on Xft.

 > Gave up at this point but promised I would get back to it. I now have to wipe 
 > this work out because Cairo has been updated.

I hope you find that things have only gotten better.

Keep us posted,

-Carl