It is not about particular case, it is about whole environment.
* interactive:
shell (profile setup).--> source editing / patching
`-> building parts / doing tests
where profile is one particular source tree with particular
config/development goals. On multiple terminals (sessions), one
may just type in favorite shell `wana profile-xx` and environment
is set up there. I.e.
+ where ever you are, it's easy to go to current obj or src tree,
+ quilt knows its setup
+ kbuild does also
+ tracking files, sent to editor (e.g. emacsclient / emacsserver)
o easily composing file / change sets to be operated by quilt
o kbuild knows exactly what to check and possibly to rebuild
+ all actions are written to history, that can be imported into any session
o saving sessions
o restore sessions: checking profile consistency / updating
+ less ugly (e.g. just stupid bash command line) user interface
o even ordinary command line can be improved much-much more in
terms of efficiency and comfort
o more nice-looking information of what is happening and how is
happening
* automatic:
running setup of selected profiles:
o patch/update sources
o configure and (cross) build multiple source trees with multiple output
trees each.
o run time testing: emulators, hardware.
Many ideas, collected in kbuild-2.5-history.tar.bz2 back in 2000, are
still interesting and useful.
More i do development, more i realize, that i spend too much time to
do trivial and repeating things. And this time will not go less, if
something like that will be by hand.
I'd really like to see a work flow of best development staff, because
behind patches i can not see anything. And frankly, i doubt there's
anything significant there. The only sharing of tools i can see is
patch scripts (now quilt), diff-tools, linux/scripts. Still just tools.
There's no environment, where peo...
