discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pswrap and includes


From: Juliusz Chroboczek
Subject: Pswrap and includes
Date: 08 Jan 2001 19:20:08 +0100

Hello,

We're speaking about making some minor changes to the XFree86 version
of pswrap.  I was wondering whether any of you would have any comments
to make.

I'd be grateful if you could CC any replies to 

  dps-devel@lists.sourceforge.net

Regards, and thanks for your help,

                                        Juliusz Chroboczek


From: trevor <twoerner@ica.net>
Subject: [Dps-devel] *.c output #includes from pswrap
To: dps-devel@lists.sourceforge.net
Date: Sun, 7 Jan 2001 23:00:33 -0500
Reply-To: twoerner@ica.net

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/

_______________________________________________
Dps-devel mailing list
Dps-devel@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/dps-devel

From: Juliusz Chroboczek <Juliusz.Chroboczek@ens.fr>
Subject: Re: [Dps-devel] *.c output #includes from pswrap
To: twoerner@ica.net
CC: dps-devel@lists.sourceforge.net
Date: Mon, 8 Jan 2001 19:03:36 +0100 (MET)

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

I really don't see how a pswrap stub could refer to the psops.  Unless
somebody knows better, I think we may as well remove the psops.h
include.

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

I see.  So do you suggest including dpsclient or dpsfriends?  I guess
we may as well leave dpsclient.

I'll forward these mails to the DGS developers to see if they have any
comments.

                                        Juliusz

_______________________________________________
Dps-devel mailing list
Dps-devel@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/dps-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]