Commit Graph

10 Commits

Author SHA1 Message Date
Michael Shigorin
0ec7d7cd01 check vigorously for installed mkimage
It was briefly mentioned in QUICKSTART but somehow managed
to evade the commandlines provided.  And while at it, let's
make errors like this more explicit to avoid extra lookups.
Oh, and fix QUICKSTART so that readers miss the hassle. :)

Thanks Vladimir Karpinsky for pointing this problem out.
2012-01-04 22:33:53 +02:00
Michael Shigorin
2f307ffffb main.mk introduced, lib/*.mk partially rewritten
The former toplevel Makefile is now toplevel main.mk;
this change allows for multi-target, multi-arch processing
in the current toplevel Makefile.

As the "build" symlink semantics change quite considerably
when one is doing bulk builds (several pruned builddirs might
be useful for comparison), BUILDDIR is now much more likely
to be recreated: the cases when it will persist are when it's
either a single-image build or when the prefix hasn't changed.

There are some more or less subtle bugfixes and enhancements
all over the map as well.

Done within 20111230..20120102 timeframe, actually...
2012-01-02 21:01:09 +02:00
Michael Shigorin
e89a0f1c62 lib/build.mk: tweak the optimizer
$(SHORTEN) is better in the midst of the pipe
so that greps are terminal and can sense the tty
(or the lack thereof in case we're logging further).
2011-12-08 09:30:06 +02:00
Michael Shigorin
390f4f6bc8 lib/build.mk: add basic CHECK support
The idea is to check:
- the reachability of every target
  used to build the image in question;
- the availability of all the package lists
  and subsequently packages for that image;
- the lack of "dangling" intermediate targets,
  features, pkglists, hooks etc.

So far only the first step is implemented --
it's easy and somewhat helpful already for
  make CHECK=1 all
2011-12-06 14:22:20 +02:00
Michael Shigorin
b52ff4ef91 lib/build.mk: different colours for different outcomes
As was (quite reasonably) asked by someone and me too,
why should a successful build yield a *red* line
(a grep's default)?

So now it's new and improved, 25% free and so forth:
with a successful build you get a green line, while
errors from a broke one result in red ones.

Clinically tested in both b/w and w/b colour schemes;
in case you're not satisfied, please return original
ANSI_OK and ANSI_FAIL values to the colour dealer
and pass your favourite ones instead.
2011-11-21 13:52:41 +02:00
Michael Shigorin
07fdc6dd9b further toplevel logging tweaks
Essentially some more polishing:
- image path extracted from downstream build log;
- extended error/warning regexp a bit so those with
  color grep options get even prettier output.

Notes:
- "1024" a magic number (briefly explained when introduced)
  moved to a sort of variable;
- "100 lines" for tail(1) is a rule-of-thumb taking into account
  typical amount of hasher/mkimage exhaust given GLOBAL_VERBOSE.
2011-11-07 00:01:36 +02:00
Michael Shigorin
cd3e47c562 introduced NICE variable
This one regulates the build wrapper: if the value is non-empty
then nice(1) and ionice(1) will be attempted so that the build
behaves better in regard to other tasks running on the system.

A few doc/variables.txt updates along the way.
2011-11-07 00:01:36 +02:00
Michael Shigorin
30b1aa9be6 toplevel build report now timestamped
Thanks torabora@ for yet again seemingly obvious feature request
which strangely managed to evade implementation before.

On an afterthought, mass builds would suggest too much coffee
instead of a progress indicator -- so implemented the latter.

NB: the actual downstream-make-calling rule would expand the "naive"
$(shell date) too early: the rule is evaluated before starting its
execution, and as it's the time consuming one the shell evaluation
was in need, not make's.  The result is less generally available
(needs to be double quoted and won't work inside e.g. awk programs)
but way more precise.
2011-11-07 00:01:36 +02:00
Michael Shigorin
895fae7d82 BELL support
Implemented opportunistic alarm support as proposed by torabora;
the actual result depends on readline and/or terminal settings
(read up on "visual bell" vs "audible bell" in case it's wrong).

TODO: this ought to be shifted downstream when proper logging
framework is there.
2011-11-04 16:54:41 +02:00
Michael Shigorin
d5a5941f96 official {distro,ve}/* support
This is quite a large-scale change since mkimage-profiles got used to
baking distributions over the last year, and virtual environments are
quite different, so e.g. image.in/Makefile had to be split in two with
the main part of it moved into features.in/iso/lib/.

Short overview:

- features.in/Makefile: lib/ support
  (supporting VE images requires dynamic modifications
  to image.in/Makefile before starting the build;
  the most natural way to achieve that seems to use
  features mechanism along with makefile include dir)

- packaging format related part moved into features.in/pack
  (should be better prepared for diversity either)
- features.in/iso renamed to features.in/build-distro
- features.in/ve  renamed to features.in/build-ve
  + NB: these could not be merged as e.g. features.in/build
    due to completely different script hooks

- lib/image.mk renamed to lib/build.mk
- image, config, log postprocessing moved downstream
- added a sort of a topping in the form of lib/sugar.mk
- assorted style fixups (like ifeq usage)

- clean.mk: reliability fix (the problem was observed by Oleg Ivanov
  and me too but finally it did get the attention quantum)

- reviewed, updated and extended docs
  + QUICKSTART: should be[come] a step-by-step guide
    (thanks Leo-sp50 for prodiving feedback)
2011-11-04 16:54:41 +02:00