After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 124285 - Changed versions in gnome/Makefiles doesn't give rebuild
Changed versions in gnome/Makefiles doesn't give rebuild
Status: RESOLVED NOTABUG
Product: GARNOME
Classification: Deprecated
Component: general
unspecified
Other opensolaris
: Normal normal
: ---
Assigned To: Jeff Waugh
garnome list
Depends on:
Blocks:
 
 
Reported: 2003-10-10 10:03 UTC by Jonas Jonsson
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jonas Jonsson 2003-10-10 10:03:25 UTC 
If I build, for instance, meta/gnome-office, then update the
version-numbers of libgsf and gnumeric, and do a "gmake install" in
meta/gnome-office, nothing happens!

The build system should notice that there are new unistalled versions of
the software, shouldn't it?
Comment 1 Jens Bech Madsen 2003-10-10 13:57:17 UTC 
You need to run 'make clean' in the garball after changing the version
number. That will clear out the previous build directory and, more
importantly, the cookies which keep track of the build state of the
garball.

An alternative is to remove the cookies directory in the garball.
Comment 2 Jens Bech Madsen 2004-01-02 09:35:41 UTC 
Another way to fix this would be to put the version number in the
cookie names. This way you could just change the version number and it
would rebuild.
Comment 3 Paul Drain 2004-09-20 01:53:48 UTC 
Actually, the correct way to do this is to increment the version number in the
relevant Makefile, then run 'make makesums' from it's directory, which will get
the file and upgrade the checksum.

Then you can run 'make install' to install the new version.

This issue isn't really a bug though, marking as such.