[bt-devel] current CVS doesn't build

[Torsten Uhlmann]

>>>>> "Thomas" == Thomas Philpot <tjphilpot@ou.edu> writes:

    >> This is a concern for me as well As I am getting close to the
    >> point where I will be doing some work on the Install Manager, and
    >> being new to BibleTime, Sword, C++, QT, and KDE Libs I am feeling
    >> like it would be almost impossible for me to do any significant
    >> work.

    > Ditto...

    > I'd love to help out, but I can't even seem to get the kde CVS to
    > build.  I've been trying for 2 days with CVSup, but kdebase won't
    > build.  Anybody else having trouble with konq_factory.cc in
    > kdebase?

Ok I know it is hard to deal with stuff that changes so fast but, as is
proposed be the CVS team a 1.0 version of KDE2 will be released in
Spring. Unless we would code very fast with KDE1 our work would be in
vain. When our version comes out, it will be for a gone environment. Now
to the libs:

Qt is fairly stable. It is just a snapshot because some features
additional to qt-2 are used. The API shouldn't change though.

SWORD-1.5 is stable for me as well. I can though only create a static
lib but I don't really care at that point.

KDE. You _only_ need kdesupport and kdelibs as basis for bibletime
development. They compile here since a few weeks without any error. But
there are a few things with moc files. Use the line:

find . -name "*.moc*" |xargs rm -f 

to delete _all_ moc generated files. make clean forgets some. This could
be a problem with your .cc file. There _are_ bugs in kcontrol/display
kcontrol/kdm
Just remove them from kcontrol/Makefile after the crash and redo make &&
make install.

If you want to compile KDE please use qt-copy from cvsup since this one
is the one KDE developers use. So you make sure you always have the
right qt.

BTW, I have to set a link on moc in the qt bin dir. But you will see if
moc isn't found :)

Joachim, maybe you can add those questions to our faq?

    >> My first thought for any error will be that I have made a
    >> mistake, and I will probably spend hours looking.  This is
    >> probably not bad, as it will force me to clearly understand what
    >> I am doing.  But then I will have to try to determine in which of
    >> the snapshots I am getting a particular error.
    >> 
    >> My development experience to this point has been code based on
    >> stable libraries.  What sort of activities would lead to the best
    >> approach in an environment where we are using 3 different beta
    >> libraries?  (QT, KDE and Sword) Can someone suggest an approach
    >> where I can easily determine where an error might be, and the
    >> best approach to solving the problem?

    > In my (limited) experience, it's best to start with your own code
    > as the potential source of problems.  If you think it might be in
    > someone else's code and you're using beta code, try to see when
    > the code was revised last.  I.e., check the code and CVS for
    > updates. If there has been an update, see what was changed.  It
    > may be that the part that is giving you trouble has been unchanged
    > for weeks.  From there, you're own your own.  Unfortunately, I
    > can't give you a simpler answer than "Look at the Code."  Unless
    > of course there is someone else near by who can look at the code
    > with you. :P "Given enough pairs of eyes, all bugs are shallow"
    > -Linus

    > This should of course be taken with a grain of salt, since, as i
    > mentioned before, I can't get the CVS of kdebase to build for me
    > and I have no clue where the problem lies.

    >> >Thsnks for any guidance. > >-- > Darwin Gregory > > Creation is
    > more scientifically valid than evolution!


-- 

best regards,
Torsten Uhlmann

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TUhlmann@gmx.de
TUhlmann@debis.com

http://www.tuhlmann.purespace.de
http://www.bibletime.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wise men still seek him!