[HEAD branch] a couple of advices

[Simon Hausmann]

On Sun, Dec 22, 2002 at 11:56:04AM +0100, Luciano wrote:
> On Sunday 22 December 2002 02:21, Simon Hausmann wrote:
> > On Sat, Dec 21, 2002 at 11:49:44PM +0100, Luciano wrote:
> > > Hello,
> > > I'm a bit further in my quest for a compilable HEAD.
> > > However, the changes that I'm about to commit are a bit less trivial than
> > > those I submitted earlier, so I would appreciate some suggestions.
> > > Here are the changes I'm about to commit:
> > >
> > > * the new khtml code needs the interfaces/kio/html.h include file.
> > >   The include file is pretty trivial, containing only an enum.
> > >   My change involves adding the interfaces directory to CVS
> > >   under kdesrc, and a Makefile.am with the single line
> > >   SUBDIRS = kio
> > >   in it, and a change in the prepare_kde_src script to copy the needed
> > > files in the kdesrc/interfaces/kio subdirectory. Is this the correct
> > > approach? I don't like adding more stuff than necessary, but this seems
> > > necessary to me.
> >
> > I'm not sure I understand this. Neither does kdelibs/interfaces/kio
> > exist nor can I find html.h .
> 
> This is strange. I verified on webcvs that it is a KDE3.1 addition.
> I'm currently compiling against the kde3.1 kdelibs, since the release tag is
> already set, and they are going to be available soon for general use.

Sorry, I'm stupid. I dunno how I messed up my checkout but now I see
interfaces/kio/html.h as well. Sorry :) . I agree with your idea of
copying over the directory and the file as part of prepare_kde_src.

> > > * the second change is needed to compile th kssl subdir.
> > >   As it is now, the original configure.in.in is copied by the
> > > prepare_kde_src script, but in it the AC_OUTPUT(kio/kssl/ksslconfig.h) is
> > > commented out and furthermore it creates the file in the wrong place. So
> > > I'll add configure.in.in to CVS and remove the 'cp' from the script. This
> > > is annoying, since this way changes to the original config.in.in should
> > > be tracked, but on the other hand, we are already cherry-picking the
> > > source files of the kssl directory.
> >
> > I don't understand why this is needed either. There is a reason why
> > the AC_OUTPUT is commented out: AC_OUTPUT / AC_CONFIG_FILES may be
> > expanded only once. This is why the cvs.sh script greps for 'dnl
> > AC_OUTPUT' , collects all the arguments and puts them all into a
> > single AC_CONFIG_FILES. This has worked in the past, I can't see why
> > it shouldn't work anymore. Was there any specific error message you
> > got?
> 
> I don't remember the exact error message, however ksslconfig.h is needed
> to compile the kssl directory:

Ok, seeing that.

> the command grep ksslconfig.h *.h returns the following output:
> 
> kopenssl.h:#include "ksslconfig.h"
> ksslcertificate.h:#include "ksslconfig.h"
> kssldefs.h:#include "ksslconfig.h"
> ksslpkcs12.h:#include "ksslconfig.h"
> ksslpkcs7.h:#include "ksslconfig.h"
> ksslutils.h:#include "ksslconfig.h"
> 
> An alternative solution could be adding a file "ksslconfig.h"
> under dropin/kssl that includes config.h
> Is that better?

I see two solutions: Either copy over ksslconfig.h.in (as part of
the build process) , which is what ksslconfig.h is generated from or
we go for your solution with a dummy ksslconfig.h that includes
config.h . Both are somewhat equivalent, but I think the former is
more future proof. Might be that George adds more things to
ksslconfig.h(.in) in the future.

> > > An issue I really need advice on is about the kfileitem.h in the
> > > dropin/kio directory. It redefines UDSEntry, which is also defined in
> > > kdesrc/kio/global.h The problem is that this time kfileitem.h and
> > > global.h are both included by some files, so a comflict happens. As a
> > > temporary workaround, I have commented out the kfileitem.h definition,
> > > and made the code related to it a NOP, however, I need to know what uses
> > > the kfileitem class. Worst case, it needs to be reimplemented with the
> > > global.h definition...
> >
> > Hm, I'm a bit puzzled. I can't see KFileItem being declared in
> > kio/global.h in HEAD kdelibs, only in kfileitem.h ...
> 
> Yes, but the KFileItem class uses the UDSEntry type, which is
> defined in global.h.

Ahh, UDSEntry, I see. Yes, you're right on that, sorry I missed that
tiny detail. Hmmm, unfortunately I don't have the konq/e sources
here right now. Offhand I'd say re-using the one from kdelibs should
be fine. IIRC it should require only a minor adjustement in the
KFileItem wrapper (holding the stat result in the real uds entry) .

Simon

P.S.: Apologizes for the delays (in the replies) . My net access is
currently limited to email over dial-up, rather infrequent, due to
me being on xmas holidays.