IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This one reduces the amount of output that's only
interesting when one is actually watching the console
during builds (at least the early stage) -- these tend
to look boilerplate and be useless when inspecting the
output of a large batch build like [[regular]] one.
The __frontend variable was introduced to address the needs
of alterator-mkimage module: list the images available in
one column, purge the builddir.
Looks like we should consider other cases with redirected
stdout (cron builds, piped calls, etc) like fundamentally
non-interactive and behave the same.
So commit 3a8af6b55d888d25c1d97561ed2ecf37ff28ad71's
description is wrong now; the current cleanup rules are:
- if CLEAN=0 or DEBUG>1, don't do it;
- if CHECK or REPORT is set, don't do it;
- otherwise if at least one of the following conditions is true:
+ there's more than one target being built in a row;
+ stdout was redirected (cronjob, alterator-mkimage...);
+ metaprofile directory is read-only
...then do a distclean.
If that doesn't suit your needs, describe the particular
situation please.
Thanks cas@ for wondering aloud whether greppable output
is unsupported with `make help'.
The behaviour that sort of settled didn't actually follow
the principle of the least surprise when one really wanted
to have BUILDDIR available for inspection; DEBUG=2 would be
effective to achieve that but CLEAN=0 would not.
Thanks led@ for spotting and reporting this.
The prerequisites for a cleanup after a successful build
were somewhat weird at this point; now the rules are:
- if DEBUG level is more than 1 or CHECK is set, don't do it;
- otherwise if at least one of the following conditions is true:
+ there's more than one target being built in a row;
+ the build was run by e.g. alterator-mkimage;
+ metaprofile directory is read only
...then do a distclean.
If these are still weird or feel unsuitable for profile hacking,
drop me a note (or a patch).
The purpose is being able to examine particular target interdependency
graph for a given image having been configured to avoid convoluted
dependencies (loops in particular).
The implementation is based on SHELL hook hint by John Graham-Cumming:
http://cmcrossroads.com/ask-mr-make/6535-tracing-rule-execution-in-gnu-make
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...
First, let's not do rsync --delete on an unverified target dir
again: the lesson was learned during a subway hacking session
and I must say that SSDs are frightening fast (even if it was
more than a second to realize what happens and terminate the
extermination before it got /home, thanks xterm).
Second, let's use a variable for common name and make's own
realpath function instead of external binary.
CLEAN is so useful and fiddling with .work chroots does
demand knowledge (hsh-shell is handy btw); so unless we
really get our hands dirty, let's spare ours preciouss
tmpfss.
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.
If you make distro/live-builder.iso, the result is an image
containing almost everything (short of actual full enough
repository) to rebuild itself. It will attempt to configure
eth0 with DHCP and reach http://ftp.altlinux.org for packages.
RAM requirements start with 2Gb, self-build is accomplished
on a 4Gb host with "make CLEAN=1 distro/live-builder.iso".
Packages required for "make distro/syslinux.iso" get included.
(some due fixups all over the place too)
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)
