[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE CVS udate question
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-30 15:52:04
[Download RAW message or body]

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 <<

[prev in list] [next in list] [prev in thread] [next in thread]