On Sat, 2002-03-16 at 09:00, Frederic Gobry wrote:
> > I'm getting a little tired of copying over picogui's headers to
> > cli_c and themetools when i make changes, and when new client
> > libraries are written (my current task is preparing the network code
> > for this) the problem will only get worse.
> 
> Indeed, I was wondering if you had some magic script or so to ensure
> there was no incoherence between the two...
> 
> > is having a "make install" in pgserver install the headers from
> > pgserver/include/picogui/*.h into /usr/local/include/picogui. Then,
> > the client libs and theme tools would reference those headers. Extra
> > headers for the specific client libs would be added in
> > /usr/local/include and /usr/local/include/picogui when "make
> > install" is run in cli_c.
> 
> This should be no problem, just another --with-... option to the
> configuration script.
> 
> > The advantage of this method is that cli_c and themetools don't need
> > a copy of pgserver's headers, only the new headers for cli_c. The
> > disadvantage is that you have to install pgserver before you can
> > build cli_c.
> 
> It depends on what you expect: if there is a need for installing both
> everytime, then it's maybe simpler to put everything in a common
> project (from the autoconf point of view). On the other hand, if you
> insist on the separation, maybe a third part containing the protocol
> only could solve the problem: cli_c depends on proto, pgserver depends
> on proto, and everybody can install what is needed...
> 

This perhaps might sound simple, but why can't the -I gcc line
be used to find locations of headers. Some are common, some are
client specific, some are server specific. We could have a 
headers/common.. or something like that. Or perhaps all
common ones are in pgserver/include/picogui.. 

This is just to continue to discuss the options available. 

Eric



_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel

Reply via email to