[Cairo] make error with cvs cairo
spitzak at d2.com
Tue Sep 16 10:08:28 PDT 2003
On Tuesday 16 September 2003 08:01 am, Carl Worth wrote:
> > 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).
I'm not clear if somebody calling Cairo would need to call or use any symbols
in ic.h. If not, I really recommend that it not be in the public header
files. You can always include it in the source files of Cairo that use it.
> > 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.
Getting Xlib out of any public header files is extremely important. It
pollutes the namespace with many symbols and typedefs and macros. I would
prefer that void* or other standins be used in any structures that have a
field for xlib objects. In my own code I am forced to #define Window XWindow
and #undef Window around any inclusions of xlib.h (and same for atom, and I
may have to add a few others). Any public header files that include xlib.h
PS: the same is true for <windows.h> on Win32, except it is probably worse,
defining macros like ERROR and Color which are extremely annoying.
> > And get rid of typedefs like CairoDouble
> There has never been a typedef for CairoDouble nor anything like
Sorry I meant XrDouble. I really recommend these be eliminated from Xr as
well. Using them correctly requires Cairo to include Xr.h and thus xlib.h and
thus breaks things as described above. So everybody has to assumme they are
the same as double anyway.
Also notice that the existence of these things actually made me misunderstand
the code, so that when a *real* typedef was encountered (XFixed) I assummed
it was just another stupid typedef that could be replaced with int.
> > 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?
Yes. When install.sh tries to create a directory, I think it gets confused by
symbolic links and perhaps by mount points. It thinks it has to mkdir those
even though they exist, and then complains when mkdir fails. On my machine
"mkdir -p" seems to work correctly, but I guess they are not calling this
because it is not portable?
> > 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.
This is of course the typedef that I mis-interpreted because of all the
XrDouble and XrInt and other unnecessary typedefs.
First I would get this out of the headers if it is not needed by outside
users. If this is in a field in a structure, you might want to see if the
caller ever needs to allocate or copy such a structure. In many cases the
caller never does anything other than copy pointers to these structures and
pass those pointers as arguments. If not then just declaring "struct
Cairo_foo_t;" should work.
If in fact the caller needs the sizeof this structure then you do need the
typedef, unfortunatly. A comment indicating that it is for internal use would
help so no callers decare variables of that type.
If (as I suspect) this is needed
I suspect however it is a field in the structure and thus needed to give the
sizeof the structure, however sometimes you can get rid of these as long as
only Cairo allocates the structures by putting only "struct Foo" into the
> I hope you find that things have only gotten better.
Yep, going to try the newest version.
If you want, I can at least get it so that it does not require the xrender
header files to compile a program which calls Cairo, though I doubt I will be
able to get any programs to execute yet. Notice that my solution will assumme
that the declared Cairo triangle and other types are exactly equivalent to
what Xrender declares. Is this ok?
,~,~,~,~ ~ ~ ~ ~
/\_ _|_========___ Bill Spitzak
~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com
More information about the cairo