Re: Solving the config.h nightmare ?

[Daniel Reed]

On Sun, 23 Apr 2006, Bob Friesenhahn wrote:
> On Sun, 23 Apr 2006, Daniel Reed wrote:
> > typedef struct nscreen_window_t {
> >         uint32_t framebuffer[1024][768];
> >         int     x, y;
> > } nscreen_window_t;
>
> Your example seems to assume that the client app will not be manipulating 
> 'framebuffer directly'.

That can be done through an API call, to do whatever is necessary to get 
the buffer from the ncurses WINDOW, GLX Window, or the dummy .framebuffer.


> If it does (for performance reasons), then it needs 
> to know that framebuffer is an array of uint32_t with a particular size.

Is your issue that the buffer might be a uint32_t array sometimes and 
something else other times, and that needs to be communicated, or that the 
API uses the type uint32_t but that type (under that name) isn't 
guaranteed to always be usable?


> This was a great example since it represents the main bit of configury in my 
> library that needs to be remembered at install time.  The type representing 
> 'framebuffer' can be one of three possible sizes and the application is free 
> to update it.

When is the format for the buffer set, at GraphicsMagick ship time, 
GraphicsMagick build time, dependent program ship time, dependent program 
build time, or dependent program run time?

--
Daniel Reed <address@hidden>      http://shell.n.ml.org/n/        
http://naim.n.ml.org/
"A man that is truly great is he who makes the world his debtor."