Version: 1.5 (using KDE Devel) Installed from: Compiled sources Compiler: N/A OS: Linux jhbuild (gnome's build tool) gives a list of options when an error occurs. If the download fails it gives an option to try downloading again, when configure fails it gives an option to try it again same for all steps. Also it gives options to skip some steps. The most important option is to give a shell so that you can fix the option then and there itself without bothering to consult the log files. It is very helpful when you just have to install a dependency. Some other cases are needing to use sudo, removing files when disk gets full ... I have been using this a lot as it is building a lot of applications and chances of failing one thing or other is very high. Currently you have to remember which step failed and then try to resume from there manually.
In general you can just re-run kdesvn-build again and it will start again after the last step that successfully completed for a module. You can use --resume-from to start building from a given module as well for when the first 4 were fine but 5 failed. I don't in general like interactivity in the script because the normal use case from my experience is that you launch the script and alt-tab away and come back later. If kdesvn-build spent time waiting for a response instead of building packages that can be built then that aggravates the user. There are of course ways around that (timeouts, beeping when a prompt is issued) but normally what I do is have the script complete as much as it can and then report what failed. However I'll mull it over a bit and see what might be good to employ. Also, the following are already possible: * skipping steps (--no-svn, --no-build, --no-install, etc. These are not interactive however.) * bringing up a shell (kdesvn-build --run /bin/sh) * sudo (set the make-install-prefix option to sudo; if I had the chance to do it again it would be called something different but there you go. Also can't be changed interactively) * removing files. You can't remove files on call when the disk gets full but you can remove files after installation by using the remove-after-install option. (http://kdesvn-build.kde.org/documentation/kdesvn-buildrc.html#conf-remove-after-install)
Once something fails, you can't continue without a manual intervention, so it has to be interactive. In jhbuild the tool takes care of where it stopped, but here _you_ have to do it. AFAICT, the primary function of automation tools are to save you from repetitive tasks and dependencies. In jhbuild you just have to fix once, here you have to fix it then hope it actually fixed it, look out till what point we stopped, resume from there and some cases it does not resume, so you have to start from beginning. I'm not telling jhbuild is perfect, it has its own share of quirks as well, but this feature I found very useful. And when kdemultimedia failed because the disk was full, no matter what options I tried after removing some files (mozilla took a lion's share of my disk) it does not resume. Finally I had to tell it to refresh. In jhbuild you just have to fix one issue and it offers you to go to all steps (redo some or skip some) of a particular module, where you don't have to poke your head to decide which steps I should do now and try all until some works. Again all this options you have to evaluate where you expect the tool to be smart enough to do it. If it can save the history and continue with last failed step by default, that would be great. As you would be fixing the failed step and it can't continue without that step. Trying to do as much as possible is a moot point as in this case it always failed all remaining steps. You could try to complete independent steps but if steps 4,5 and 6 depends on step 3 there is no point in trying those unless you succeed in step 3. The point about a shell was to fix the problem, in this case you already got a shell when it failed, but here not only you have to fix the issue, you have to find out yourself where we stand and find out what options would work best, try it and hope it does, and keep trying until it finally does. With ability to stop at a step get to a shell fix it and once you exiting from the shell if it resumes from the failed step that saves a lot of effort. Even though I have given full access to /opt/gnome udev wanted to install it in /sbin, so this was particular to just one modules and you don't want every module to use sudo. I hope you got the scenario. I wanted to remove some other files which I don't want (like I had mozilla and openoffice occupying lots of space), after deleting unwanted files no matter what options I used it did not work. Finally a refresh is what worked. It would be great to try refreshing (for a particular module and not the entire step) if a resume fails. And it would be smart to resume from a step before the failed step when the normal resume does not work. Case in point is kdemultimedia, after lots of tries with different options I tried to remove kdemultimedia directory in the hope that it will checkout and start afresh, but it failed saying there is no such directory. In this case I would expect it to check out when it does not see a directory. It is a great tool and I like some of its features better than jhbuild especially the resume from.
Praveen, I read through your last comment and it was quite jumbled. :) What are your specific problems or requests? You make mention of automatically refreshing for a module failure. kdesvn-build actually does something like this for KDE 3.5 modules because it seemed to help for automake-based projects. However refreshing when the build is really broken just makes the overall build take longer. So for CMake modules (KDE 4) I disabled that feature by default. If build errors occur that are fixed by --refresh-build it should be a CMake bug or a CMakeLists.txt error which I'm not going to keep hacking kdesvn-build around. I think I must just be unclear as to how jhbuild operates is superior to re-issuing the command or performing the most correct action by default. You mentioned that you can drop into a shell from jhbuild, fix something, and have jhbuild restart the module skipping some steps. But this doesn't sound like something that can't be done almost as easily by having a separate terminal tab open (or using screen on a single pty) for the shell and then re-running kdesvn-build as appropriate. (i.e. if you fixed a build and want to re-run CMake, using "kdesvn-build --no-svn --reconfigure kdebase" for example). Please keep in mind that whatever I implement would need to be able to operate in the face of a kdesvn-build source update thread running in the background. kdesvn-build would be unable to retry an update in this situation for instance because it would have already moved onto the next module.
Let me try to explain the situation in a better way 1) jhbuild takes care of the history (what all packages are already built and what is failing). jhbuild wait for you to fix it and once you fix it, jhbuild continues as if nothing happened to it at all. Now if you compare that to kdesvn-build. _you_ have to know where it stopped. It just exits when something fails. 2) Now every module has different steps download,configure, build and install. Any module can fail at any of these steps. If any of the steps fails, jhbuild waits for your choice (if the modules coming after this depends on this module, there is no point in trying those). Now it offers you to go back to any of these steps or skip any of these steps. The most useful option is to chose a shell _inside the jhbuild process_ and fix any issues. Now once you exit from the shell you are given the same options. Lets say build failed because some files are missing. You could just run build again, or go back to configure. Then if you have manually fixed all the steps and you just want to go to next module you can tell it so. Currently it looks simple if you have just 6 modules in kdesvn-build but jhbuild comes real handy because if you are building say epiphany where you have about 50-60 dependencies to build. You don't want to remember what all modules failed and what all modules built successfully ... If at all you have to worry about anything that comes down to just a single module at a time. Hope it is clearer now.
You do not need to remember the failed modules. The kdesrc-build writes it to the output. Just fix the origin of the problem and rerun the kdesrc-build command. There is no point of adding a separate shell, as mpyne said, you can just open a separate tab in Konsole.