[Dps-devel] *.c output #includes from pswrap

[trevor <two...@ic...>]

On Sunday 07 January 2001 11:37, Juliusz Chroboczek wrote:
> Here's what the Solaris version does:
>
>   /* stdout generated from stdin
>      by unix pswrap V1.009  Wed Apr 19 17:50:24 PDT 1989
>    */
>
>   #include <DPS/dpsfriends.h>
>   #include <string.h>
>
>   #line 1 "stdin"
>
> Shall we follow them?  Will that work in our setup?
>
>                                         Juliusz

as it stands, the "pswrap" function that comes with XFree86-4.0.2 will 
insert the following headers into the generated *.c file:

  #include <DPS/dpsclient.h>
  #include <string.h>
  #include "psops.h"

in the example that i used (from chapter 8 of the DPS client document) 
the *.c file that is generated from the *.psw file doesn't contain any 
"psops" functions. perhaps this is because the example is too simple? 
perhaps a more complicated example would require some?

the only DPS functions the resulting *.c file contains have their 
prototypes in the file <DPS/dpsfriends.h>. so it might seem that 
including this file might be good. however, the first header file that 
is included is <DPS/dpsclient.h> which subsequently #includes 
<DPS/dpsfriends.h>. therefore, adding the <DPS/dpsfriends.h> line would 
be redundant since the first include already includes it.

so as it turns out, for this example we don't even need to #include 
<DPS/psops.h> (or "psops.h" for that matter) at all, but perhaps this 
is because the example is too simple?

so i see three options:

1) don't include anything to do with dpsops, it doesn't appear to be 
required for this example - requires modification to "pswrap" utility

2) leave "pswrap" as it is, in this case the Makefile will have to 
include an additional -I parameter to explicitly include the path which 
contains the psops.h file

3) modify the output of "pswrap" to include <DPS/psops.h> - requires 
modification to "pswrap" utility


i guess i'd go along with any of the 3 that is decided (especially if 
an "official" position exists). i'm not comfortable with 1), including 
this file might serve some purpose that isn't immediately obvious. i 
just plainly don't like 2). the standard way to include an XWindow 
header file is to place those files in a subdirectory under the 
standard X include location (which on my computer is 
"/usr/X11R6/include") and then to include a line like the following 
into your *.c code:

  #include <libdir/file.h>

it keeps the includes nicely arranged and separated. then the compile 
lines in the Makefile only have to cleanly have one -I parameter 
(namely -I/usr/X11R6/include). using the "pswrap" utility the way it is 
now arbitrarily breaks this pattern for no good reason that i can 
ascertain. why not simply write X programs like this:

  #include "gl.h"
  #include "Xlib.h"
  #include "psops.h"
  #include "Xmu.h"

and then make the build line look something like this:

  gcc -o source1.o -c source1.c -I/usr/X11R6/include/GL\
-I/usr/X11R6/include/X11 -I/usr/X11R6/include/DPS\
-I/usr/X11R6/include/X11/Xmu

? i think this starts to look stupid. "pswrap" as it stands now is 
breaking a nice convention, it should be brought back in-line. i much 
rather prefer to write *.c code that looks like this:

  #include <GL/gl.h>
  #include <X11/Xlib.h>
  #include <DPS/psops.h>
  #include <X11/Xmu/Xmu.h>

and then have a simple compile line like:

  gcc -o source1.o -c source1.c -I/usr/X11R6/include

simply then, my preference is 3), if it matters :-)

best regards,
	trevor
-- 

http://home.ica.net/~vjbtlw/