Bug 62288 - Gideon does not recognize LIB_KDEGAMES
Summary: Gideon does not recognize LIB_KDEGAMES
Status: RESOLVED NOT A BUG
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: 3.0.0a4
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-07 02:33 UTC by Ian Wadham
Modified: 2003-08-25 23:01 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Wadham 2003-08-07 02:33:31 UTC
Version:           3.0.0a4 (using KDE 3.1.1)
Installed from:    SuSE
Compiler:          gcc version 3.3 20030226 (prerelease) (SuSE Linux)
OS:          Linux (i686) release 2.4.20-4GB

$(LIB_KDEGAMES) is a recognized and distributed KDE library, but Gideon
does not recognize that library symbol and fails to load from that library.
Comment 1 Thiago Macieira 2003-08-07 02:37:45 UTC
What do you mean, exactly? 
 
In the generated Makefile, do you see that symbol be defined? Or is it a problem with the 
GUI? 
Comment 2 Ian Wadham 2003-08-07 14:42:30 UTC
Subject:  Gideon does not recognize LIB_KDEGAMES         

----- Original Message ----- 
From: "Ian Wadham" <ianw@netspace.net.au>
To: <thiagom@mail.com>
Sent: Thursday, August 07, 2003 9:52 PM
Subject: Re: [Bug 62288] Gideon does not recognize LIB_KDEGAMES


> > ------- Additional Comments From thiagom@mail.com  2003-08-07
> 02:37 -------
> > What do you mean, exactly?
> >
> > In the generated Makefile, do you see that symbol be defined? Or is it a
> problem with the
> > GUI?
> I am using the Automake Manager in Gideon, which generates Makefile.am
> files from lists of targets, files and libraries you give it.  One of the
> dialog
> boxes Automake Manager pops up accepts library names and it accepted
> $(LIB_KDEGAMES) as input.  Somewhere down the track, I use Gideon
> to compile and build my application, but I get undefined references when
> linking.  The linker has not searched libkdegames.  In Gideon's Messages
> window, the libtool command does not have libkdegames in its list of
> parameters.  I conclude that Gideon does not "know" the symbol
> $(LIB_KDEGAMES) and just leaves it blank in the libtool command.
>
> The bugs are:
>
> a) (62288) Gideon SHOULD know $(LIBKDEGAMES) and give it a
>     valid value.  It is a recognized and distributed KDE library now.
>
> b) (62289) If Gideon does NOT know $(LIB_KDEGAMES), or any
>     other symbol     I may enter (or mis-type) it should tell me about
that
>     as soon as I enter it, not leave me to find out the hard way when my
>     application fails to build.
>
> Re the generated Makefile ... I do not look at it.  I am relying on Gideon
> to
> generate it and get it right.  That is one of Gideon's main functions.
>
> Regards, Ian W.
>

Comment 3 Thiago Macieira 2003-08-07 15:20:10 UTC
I've just checked admin/acinclude.m4.in. There's no test for LIB_KDEGAMES there. It's only 
defined if you add this to your configure.in.in: 
 
if test -d $srcdir/libkdegames ; then 
        AC_SUBST(LIB_KDEGAMES, "\$(top_builddir)/libkdegames/libkdegames.la") 
        AC_SUBST(LIB_KDEGAMES_DEP, '$(LIB_KDEGAMES)') 
else 
        AC_SUBST(LIB_KDEGAMES, "-lkdegames") 
        AC_SUBST(LIB_KDEGAMES_DEP, "") 
fi 
 
(taken from kdegame's configure.in) 
 
Still, the wish for Gideon checking of entered parameters is valid. Gideon will have to scan 
the generated Makefile.in to see if it's defined and warn if not. 
 
(yes, it's a wishlist item; it's a feature that doesn't exist) 
Comment 4 Harald Fernengel 2003-08-25 22:49:02 UTC
Sorry, this is not possible at all. The autoconf stuff is a jungle of 
shell-scripts, there is no way we can find out which variables are set or not. 
If you want less brain-damage, please tell the automake/conf guys to fix their 
system and make it more transparent. 
Comment 5 Stephan Kulow 2003-08-25 23:01:32 UTC
/me points Harald to autoconf --trace=AC_SUBST 
Comment 6 Ian Wadham 2003-08-26 08:16:31 UTC
Subject: Re:  Gideon does not recognize LIB_KDEGAMES         

> ------- Additional Comments From harry@kdevelop.org  2003-08-25
22:49 -------
> Sorry, this is not possible at all. The autoconf stuff is a jungle of
> shell-scripts, there is no way we can find out which variables are
> set or not.
>
Exactly my problem, Harald ... "jungle" is a good word ... or perhaps it's
like Schrodinger's cat.  From a developer's point of view, you cannot tell
if your application is alive or dead until you open the box (i.e. try to
build and run it).  That's why I'm looking to KDevelop to provide some
early diagnostics of undefined's in the "make" environment.

> If you want less brain-damage, please tell the automake/conf guys to
> fix their system and make it more transparent.
>
Please do.  I don't know who or where they are.  Here are some stats ...
2319 lines of Makefile's for a minimal KDE application (with source
code as generated by Gideon): 404 lines of Makefile's to compile and
build the entire Qt 3.0.2 library, examples, tutorials and non-trivial
apps like QDesigner (using QMake) ... and the Makefile's are such that
even I can understand them.  I am thinking of writing an article entitled
"Automake considered harmful", echoing Dijkstra's classic about GOTO.

Comment 7 Ian Wadham 2003-08-26 08:16:31 UTC
Subject: Re:  Gideon does not recognize LIB_KDEGAMES         

> ------- Additional Comments From coolo@kde.org  2003-08-25 23:01 -------
> /me points Harald to autoconf --trace=AC_SUBST
>
Harald, KDevelop itself generates the "auto4te" subdir, with file
"traces.0", which contains evaluations of all the LIB_ symbols and
lots of other stuff too, but, as expected, LIB_KDEGAMES is
not there.  I have defined it in my Shell env now, so perhaps
KDevelop should also check there when validating input.

I would say that whoever maintains those macros should add
LIB_KDEGAMES, since it is now a standard KDE library.

Please reconsider my problem.  I am sure you can add some
needed input validation with little effort.  My other request, for a
list of commonly used symbols and their current assignments, should
not be hard to implement either.  See bugs 62289 and 62291.