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

List:       kde-devel
Subject:    Re: cmakekdeall
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2009-01-20 0:34:17
Message-ID: gl366c$rjg$1 () ger ! gmane ! org
[Download RAW message or body]

Shai Berger wrote:
> Hi all,
> 
> I would like to replace the cmakekdeall shell function in 
> http://techbase.kde.org/index.php?title=Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc
> with the following version:
> 
> function cmakekdeall {
> 
>         FOLDERS="kdesupport KDE/kdelibs KDE/kdebase \
>                 KDE/kdepimlibs KDE/kdepim KDE/kdesdk \
>                 KDE/kdegraphics KDE/kdevplatform KDE/kdevelop \
>                 "
>                 # Add others or remove to taste, e.g.
>                 # KDE/kdemultimedia KDE/kdenetwork KDE/kdeutils \
> 
>         cd && cs # go to src root
>         svn up $FOLDERS
> 
>         for f in $FOLDERS; do
>             cs $f && cmakekde || return
>         done
> 
> }
> 
> This improves the existing function in two respects:
> 
> 1) It fetches the sources in a single svn command. Although I'm not sure it 
> guarantees a single version, it certainly improves the chances for it, and 
> helps consistency. The current version builds each module after fetching it, 
> so not only are there separate svn commands, there are significant time gaps 
> between their invocations. (Note: In the scheme set up in the tutorials, the 
> different folders are each checked out separately -- src/KDE is not a SVN 
> working copy).

Updating is done in cmakekdeall? Hmm... well, can't say I ever had that 
function (the scripts I have are based on something pre-4.0 IIRC and 
I've never looked at how they've changed, and mine have diverged quite a 
bit since that point.) Personally I have updates done as a separate step 
(that includes filtering the result to something that is readable 
without needing a huge scrollback, and prominently highlights merges and 
conflicts). But then, my setup isn't meant to be fully automated.

> 2) In case of build failure, the process stops.

As Michael pointed out, perhaps not the best idea. My "build everything" 
also stops on failure, except that "build everything" is an alias for 
"build <list-of-everything>". IOW, when something fails, it's easy to 
resubmit as "build <list-of-packages-after-failure>". That sort of 
ability might be useful to have. Of course, that /also/ can't be run 
unattended.

What could work is:
- build the core (support, libs, base); abort if anything fails
- build the rest, keeping a list of packages that failed

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
morphir: so much confusion :S kmake, kdemake, qmake make cmake etc.
logixoul: you forgot cmakekde :)
morphir: and bakemeacake

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]