Tarballs of my game do not define $(LIB_KDEGAMES).
Consequently, the game program will not build unless the
receiver has somehow defined that symbol elsewhere in his/her
system. I have "export LIB_KDEGAMES='-lkdegames'" in my
bashrc file. I did that 3 years ago in order to survive and keep
working, but am sure it is not right. What is the proper approach?
This came up when I sent a tarball of KGoldrunner to a friend,
with some bug fixes for him to test. He programs in Java and
uses Debian distrib, so had to set up all of C++, Automake
and friends, KDE development, etc. from scratch. The above
was the final problem. It had us flummoxed for 2 weeks!
I'll be interested in the answer. I thought LIB_KDEGAMES
was fully incorporated into KDE (3.4) now, but it seems not.
All the best, Ian W.
kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

A Diumenge 16 Juliol 2006 04:37, Ian Wadham va escriure:
Tarballs of my game do not define $(LIB_KDEGAMES).
Consequently, the game program will not build unless the
receiver has somehow defined that symbol elsewhere in his/her
system. I have "export LIB_KDEGAMES='-lkdegames'" in my
.bashrc file. I did that 3 years ago in order to survive and keep
working, but am sure it is not right. What is the proper approach?

This came up when I sent a tarball of KGoldrunner to a friend,
with some bug fixes for him to test. He programs in Java and
uses Debian distrib, so had to set up all of C++, Automake
and friends, KDE development, etc. from scratch. The above
was the final problem. It had us flummoxed for 2 weeks!

I'll be interested in the answer. I thought LIB_KDEGAMES
was fully incorporated into KDE (3.4) now, but it seems not.

My / has LIB_KDEGAMES correctly defined.

Albert

All the best, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Tarballs of my game do not define $(LIB_KDEGAMES).
Consequently, the game program will not build unless the
receiver has somehow defined that symbol elsewhere.

From: "Albert Astals Cid" <aacid (AT) kde (DOT) org>
My / has
LIB_KDEGAMES correctly defined.

I think you may be compiling and building all of kdegames
and that LIB_KDEGAMES gets defined in the kdegames top
directory. My suspicion is it's in "configure.in.in".

I wish to tarball a single game and have "./configure" and
"make" work correctly for the receiver. Should I add a copy
of kdegames's "configure.in.in" to my tarball?

Cheers, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

A Dimarts 18 Juliol 2006 03:27, Ian Wadham va escriure:
Tarballs of my game do not define $(LIB_KDEGAMES).
Consequently, the game program will not build unless the
receiver has somehow defined that symbol elsewhere.

From: "Albert Astals Cid" <aacid (AT) kde (DOT) org>

My / has
LIB_KDEGAMES correctly defined.

I think you may be compiling and building all of kdegames
and that LIB_KDEGAMES gets defined in the kdegames top
directory. My suspicion is it's in "configure.in.in".

I wish to tarball a single game and have "./configure" and
"make" work correctly for the receiver. Should I add a copy
of kdegames's "configure.in.in" to my tarball?

You could try svn2dist script on kdesdk/scripts, theoretically it creates a
tarball of the package you want.

Albert

Cheers, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Tuesday 18 July 2006 03:27, Ian Wadham wrote:
Tarballs of my game do not define $(LIB_KDEGAMES).
Consequently, the game program will not build unless the
receiver has somehow defined that symbol elsewhere.

From: "Albert Astals Cid" <aacid (AT) kde (DOT) org>

My / has
LIB_KDEGAMES correctly defined.

I think you may be compiling and building all of kdegames
and that LIB_KDEGAMES gets defined in the kdegames top
directory. My suspicion is it's in "configure.in.in".

I wish to tarball a single game and have "./configure" and
"make" work correctly for the receiver. Should I add a copy
of kdegames's "configure.in.in" to my tarball?

Actually you should not use internal kdegames variables in your non-kdegames
tarball ;-)

But yes, looking at the kdegames/configure.in.in, this file indeed has support
for cvs2pack, so copying this file to your tarball should fix the problem.

The problem here is (in case you care about the explanation) that in kdegames
LIB_KDEGAMES in your projects needs to be defined to -lkdegames, however
doing the same in kdegames would be very bad: we might link against an
existing (installed) libkdegames, which may or may not provide all symbols
(i.e. classes, methods, functions, ) that are required. So kdegames needs
to define it to $(top_builddir)/libkdegames/libkdegames.la.
That's why we can't easily use "-lkdegames" in kdegames and use the
LIB_KDEGAMES variable instead.

Cheers, Ian W.

CU
Andi

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

From: "Andreas Beckermann" <b_mann (AT) gmx (DOT) de>
Actually you should not use internal kdegames variables
in your non-kdegames tarball ;-)

Ah well, we have a rather relaxed attitude to authority
in Australia ;-) but my game *is* a KDE game (KGoldrunner)
and I wanted a friend to be able to try out some bug fixes before
I check them in and without him having to know too much about
KDE Devel, SVN etc. He's a Java developer and that's what
tarballs are for, to let others compile and install without hassles.

Besides, I have a new game I am writing and would like to do
some "test marketing" before (hopefully) making it a KDE game.
In both cases I am looking for a stand-alone build and install.

But yes, looking at the kdegames/configure.in.in, this file indeed has
support
for cvs2pack, so copying this file to your tarball should fix the problem.

The problem here is (in case you care about the explanation)

Thanks, Andi, and yes I do.

That's why we can't easily use "-lkdegames" in kdegames and use the
LIB_KDEGAMES variable instead.

So here's a suggestion from an old system architect from way back.
Why not get $(LIB_KDEGAMES) defined (by default) as "-lkdegames"
in all that KDE "admin" apparatus, or whatever the CMake equivalent
will be. That's what seems to happen with other KDE libraries. You
could still re-define it to use a dev or test library in the "kdegames" dir
and so could I (for final compilation and testing), but I much prefer to
work with *stable* libraries every day.

All the best, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Wednesday 19 July 2006 08:20, Ian Wadham wrote:
That's why we can't easily use "-lkdegames" in kdegames and use the
LIB_KDEGAMES variable instead.

So here's a suggestion from an old system architect from way back.
Why not get $(LIB_KDEGAMES) defined (by default) as "-lkdegames"
in all that KDE "admin" apparatus, or whatever the CMake equivalent
will be. That's what seems to happen with other KDE libraries.

No, it is not. See for example kdelibs/kdeui/Makefile.am:
libkdeui_la_LIBADD = /kdecore/libkdecore.la
-again you cannot use -lkdecore here, as that might use an already installed
library, which would break kdelibs.

You can use "-lkdecore", "-lkdegames", "-lwhatever" if and only if you are in
a different module than the library you link against. Because then you _want_
to link against an already installed library.

You
could still re-define it to use a dev or test library in the "kdegames" dir
and so could I (for final compilation and testing), but I much prefer to
work with *stable* libraries every day.

Which is exactly what we do in kdegames: configure.in.in defines it to
$(top_builddir)/libkdegames/libkdegames.la if it resides in kdegames, but it
defines it to -lkdegames if it resides somewhere else.

So I don't see what you suggest here.

About cmake: It's probably easier here (well, most things seem to be easier
with cmake :)). From looking at it, we use things like
target_link_libraries(target_name kdegames)
and this will probably use the kdegames library target, if existing (i.e. if
in the kdegames module) and the kdegames library if not. Which is again
exactly what you need :)

btw: cmake works pretty well with kde3, too. Well, most of the time at
least ;-)

All the best, Ian W.

CU
Andi

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Wednesday 19 July 2006 08:20, Ian Wadham wrote:
So here's a suggestion from an old system architect from way back.
Why not get $(LIB_KDEGAMES) defined (by default) as "-lkdegames"
in all that KDE "admin" apparatus, or whatever the CMake equivalent
will be. That's what seems to happen with other KDE libraries.

From: "Andreas Beckermann" <b_mann (AT) gmx (DOT) de>
No, it is not. See for example kdelibs/kdeui/Makefile.am:
libkdeui_la_LIBADD = /kdecore/libkdecore.la
-again you cannot use -lkdecore here, as that might use an already
installed library, which would break kdelibs.

I beg to differ. I think the attached extract from "admin/acinclude.m4.in"
on the KDE 3.5 branch of SVN is what I am talking about. I think
$(LIB_KDEGAMES) could have been defined by default somewhere
in there and so would have been defined in tarballs, etc., but I guess it's
too late (ancient history) now.

You can use "-lkdecore", "-lkdegames", "-lwhatever" if and only if you
are in a different module than the library you link against. Because then
you _want_ to link against an already installed library.

Which is almost all the time for me. I'm a library *user*, not a library
developer. I think we've been talking at cross-purposes on that. My
build (Makefile.am) refers to $(LIB_KI) and $(LIB_KDEGAMES), so
people modifying libraries can build my app with their latest libraries.
The
$(LIB_KI), when I am building, evaluates to "-lkio" and brings in various
KDE libraries in whatever (stable) KDE version I have installed, but the
$(LIB_KDEGAMES) evaluates to null (unless I play tricks with
"export" or "configure.in.in") and my build fails, with unreadable
messages about functions whose names I do not recognize.

So I don't see what you suggest here.

I hope you do now.

About cmake: It's probably easier here (well, most things seem to be
easier with cmake :)). From looking at it, we use things like
target_link_libraries(target_name kdegames)
and this will probably use the kdegames library target, if existing (i.e.
if in the kdegames module) and the kdegames library if not. Which is
again exactly what you need :)

What excellent news! We used to achieve all that with environment
variables ("export") back in the bad old days. But I guess the world
is much more complicated now ;-)

btw: cmake works pretty well with kde3, too.

Thanks, I'll give it a try. I need to learn about CMake and it would
help to start with a non-trivial example that I already know.

All the best, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org