From kde-devel Mon Jul 30 15:52:04 2001 From: Martijn Klingens Date: Mon, 30 Jul 2001 15:52:04 +0000 To: kde-devel Subject: Re: KDE CVS udate question X-MARC-Message: https://marc.info/?l=kde-devel&m=99650828323780 On Friday 30 July 2021 22:17, Bastian Voigt wrote: > Hi developers, > > I am an unexperienced cvs user, that means I downloaded the sources from > cvs the first time today. > Now if I update the sources via cvs up, do I need to do a "make clean" or > something like that to remove the old object files etc. or can I speed up > compilation keeping the object files that have not changed? Can this cause > any problems? Yes, but it depends. If I want to do a quick recompile I tend to do cvs up && make, skipping make -f Makefile.cvs, configure, and make clean. _BUT_: Because of the problems that are _very_ likely to occur when doing this I mostly do this for single directories and not entire modules. And even then it is not guaranteed that it will work, though my experience is that it works about 95% of the time or so. If new directories are added you _must_ recreate the Makefiles by running configure or the create_makefiles script from kdesdk (the latter is often much faster, but _only_ creates makefiles and skips the rest of configure, so don't use if you cannot skip configure) If new configure checks are added (changes in the various .in and .m4 files often indicate that) you probably need to rerun all of configure. Probably, because the changes might not be for your platform, but I think finding that out takes more time than just running configure. Also, the make -f Makefile.cvs command creates the configure script, so if configure needs to be re-run again you probably need that as well. rm config.cache before configure is needed if your own system configuration changed (added/changed/removed libraries for example) or if an existing, cached, configure check changed its behaviour. IMO the latter is bad practice if the configure check doesn't get a new name, but my personal experience indicates that it does happen sometimes. make clean is only needed if a directory is severely modified by adding and removing files and such. Calling it every time again is safest, but takes so much extra time that I hardly do it at all. If problems arise I run make clean just in the offending dir mostly. ------------- IN SHORT: 1. For maximum safety, run the full sequence: make clean && rm config.cache && make -f Makefile.cvs && configure && make && make install 2. For everyday safety, speeding up compilation quite a lot, don't make clean: rm config.cache && make -f Makefile.cvs && configure && make && make install 3. For speeding up configure a bit, don't remove the cache, mostly works properly as well, but now we're getting more tricky: make -f Makefile.cvs && configure && make && make install 4. If no configure checks were added/changed, just create makefiles (this is nice, but due to the amount of output cvs up gives it is often too hard to determine if it is safe. In theory the cvs up output tells it all, in practice you'll probably find it hard not to overlook things): create_makefiles && make && make install 5. If no dirs were added as well, just run make (like the previous: cvs up tells you, but it is hard to determine within the rest of the output): make && make install 4. and 5. are best used in single dirs where the output of cvs is somewhat managable for the human eye and brain. When hacking code inside CVs this is probably the way to go, also because you know the code better if you're hacking a given dir... 2. and 3. are best for unattended full builds of the cvs tree 1. is for people with too much time, for occasionally starting with a _really_ clean tree (once every few months or so, first deleting $KDEDIR before install as well) and for people who package rpms or debs. > In case you are annoyed by questions like these, is there any > FAQ/HOWTO/tutorial on using KDE CVS? That question is already answered by Marcus... Martijn >> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<