including Qt libs
W. Tasin
tasin at e-technik.fh-muenchen.de
Fri Jun 16 12:10:00 BST 2000
"Rene Märten" wrote:
>
> On Fri, 16 Jun 2000, you wrote:
> > Werner Modenbach wrote:
> > >
> > > Am Don, 15 Jun 2000 schrieb OS:
> > > > ...and yet ANOTHER "cannot find Qt library" problem !!!!!!!!
> > > >
> > > > This is getting tedious (and I don't mean me going on about it !)
> > > >
> > > I agree absolutely.
> > > But what do you think should be the proper solution?
> > > Don't you think we should solve it somehow in the distribution instead
> > > reclaiming for to many people having a problem with the distribution?
> > >
> > > All I would like to have is
> > > ./configure
> > > make
> > > make install
> > >
> > > A simple question for entering the Qt-path instead of terminating the script
> > > would be the easyest. Don't you think so?
> > >
> > > - Werner -
> > >
> > > BTW: For me the work of kdevelop is outstanding! Thre might be just little
> > > things to be improved. One of them should be when creating a new project to
> > > indicate if it is based on qt-1.* or qr 2.*. The paths for qt and kde shouldn't
> > > depend on environment variables but should be part of the setup.
> > They are. You have to set the path in the kdevelop setup for KDE2/qt-2
> > for that which basically only get append during the project creation. If
> > configure fails on a qt-1.x app, you can run configure with arguments
> > >from within kdevelop where you can append --with-qt-dir= which should
> > solve the problems with qt if you know where you have it.
> >
>
> Ralf,
> Du scheinst nicht verstehen zu wollen ! Werner meint, es gebe Leute, die NICHTS
> in der shell eintippen wollen, KDEVELOP soll den kompletten Part übernehmen !!!
> Ich glaube das war verständlich ? OK, gruss aus teltow
>
> --
> Kind Regards Rene Märten
> E-Mail: Delta_x at Codewizards.org
> Buisness: rmaerte1 at visteon.com
> Home: http://www.codewizards.de/kcommander
Hmmm... let´s resume:
1) AFAIK autoconf/automake stuff has no possibility to interact with the
user apart from commandline parameters.
If there would be a possibility to do so it has to be made in the macro
collection of acinclude.m4.in (which therefore should be agreed by the
KDE guys).
2) Searching a better solution inside KDevelop (e. g. by opening a
dialog box, if configure fails) would bring us into the same trouble as
we already have with CXXFLAGS or LDFLAGS, which are not distributed to
the package, means the compilation would work only within KDevelop and
with <project>.kdevprj, but not from the console.
Even if KDevelop could handle problems like "if configure fails on qt 1
in this path, so try again with qt 2 path" (NB: this would break much
stuff from the acinclude.m4.in), it wouldn´t work at the console from a
tarball of your project!
3) I think the problem is another one. As far as I understand, the
primarily concept was to have either QT1 and KDE1 or QT2 and KDE2, but
not both together on one machine (e.g. there is still only one
environment variable QTDIR and KDEDIR, and not QT2DIR/KDE2DIR - or
another example: pathes like /usr/lib/kde/include /usr/local/kde/include
/usr/kde/include /usr/include/kde /usr/include/ as default pathes for
KDE version 2...)
IMHO the problem would be almost solved, if KDE 2 (and KDevelop 2.x ;-))
is released and will be used instead of KDE(velop) 1.x.
4) Rene: The "make distclean; make -f Makefile.dist; ./configure; make"
combination will already be done by using "Build"/"Clean/Rebuild All"...
is this what you were asking for?
5) Another NB: Once you have done a successful "./configure
[with-options]" there should be no need to start configure again with
all commandline parameters unless you delete (or you have to delete)
config.cache and/or config.h. The path options and certain other options
are cached values and extra-defines should be found in config.h, so a
second ./configure call wouldn´t depend on the options (except you
override them again with other options).
So what would be the right way to handle this?
I see no proper (do-all-in-one) solution...
Ciao
Walter
--
The KDevelop project: tasin at kdevelop.de - http://www.kdevelop.org
--
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W. Tasin, FB
04,FHM-------------------PGP-KeyID:0x7961A645----------:
<Key-Fingerprint: 1610 835F 0080 32F4 6140 6CF7 A7D0 44CD 7961A645>
<http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x7961A645&fingerprint=on>
More information about the KDevelop
mailing list