compiling latest konq-e from CVS

[Luciano Montanaro]

On Friday 11 June 2004 23:20, Boss Man wrote:
> Luciano Montanaro wrote:
> > On Friday 11 June 2004 22:13, Boss Man wrote:
>
> ...
>
> >>*** preparing konq-embed...
> >>*** preparing kde sources (from ../../kdelibs into ./kdesrc) ...
> >>mkdir: cannot create directory `./kdesrc/kdecore/malloc': File exists
> >>cp: cannot stat `../../kdelibs/kioslave/http/httpfilter.cpp': No such
> >>file or di
> >>rectory
> >>cp: cannot stat `../../kdelibs/kioslave/http/httpfilter.cc': No such
> >>file or dir
> >>ectory
> >>cp: cannot stat `../../kdelibs/kioslave/http/httpfilter.h': No such file
> >>or dire
> >>ctory
> >>rm: cannot lstat `./kdesrc/khtml/khtml_find.*': No such file or directory
> >>rm: cannot lstat `./kdesrc/khtml/htmlpageinfo.*': No such file or
> >> directory cp: cannot stat `../../kdelibs/khtml/misc/htmltags.gperf': No
> >> such file or direc
> >>tory
> >>*** applying ecma embedded_3.2.patch ...
> >>...
> >
> > These are "normal". The files were needed in previous versions of
> > konqueror embedded, but recent kdelibs do not have them. I'll fix the
> > script. It's unlikely they will be needed in the future.
>
> thanks.  i suspected that but wanted to be sure.
>
> >>after this, everything succeeds until:
> >>
> >>$ ./configure --enable-qt-embedded
> >>...
> >>checking for dcopidl... not found
> >>configure: error: The important program dcopidl was not found!
> >>Please check whether you installed KDE correctly.
> >
> > Currently, you must install kdelibs somewhere for your build environment.
> > the dcopidl program (and some other tool as well) is needed to preprocess
> > part of the sources, and making a completely standalone build seems to be
> > too much for my poor autotools expertise. (I actually included the needed
> > tools, until I realized that in a cross-compiling environment they have
> > to be compiled differently from the rest of konqueror-embedded).
>
> ok, i'll do a complete build of kdelibs before proceeding.  i thought
> the directions indicated otherwise (well, ok, the directions i read in
> the archive, dated circa last month), but no big deal.

I suspect they are a bit outdated...

>
> thanks for your help, i'm still trying to get this thing to build so i
> can actually see if i can use it.  is there a huge dependency on kapp?
> our application is built with qapp, & no, i can't change that fact.
> since kapp inherits from qapp & kconfig, i hope i can make it work with
> just qapp.
>

The KApplication class is mostly a stub. See konq-embed/dropin/kapplication.
{cpp,h}. The supplied methods are required by KHTML and KIO (DCOP messaging 
etc.), so I think it would be not so easy to get rid of the KApplication 
stub. 
Are you sure you cannot use the stub instead of the QApplication class?

Luciano

e

-- 
Luciano Montanaro //
                \X/ mikelima at virgilio.it