[Cairo] make error with cvs cairo

[Bill Spitzak]

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 
require this.

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
> it.

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 
header.

> 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