The new make-4.4 does not reset '$(1)', '$(2)', etc. when do recursively
expanding. So the functions fire spontaneously. The reason for recursive
expanding might be to use $(shell ...).

To protect the code from spontaneous execution, we add a match check
'$(0)' to the function name. The '$(0)' variable must always have the
name of our function at the time of the call. If this is not the case,
then we are out of the $(call ...) context.

From make documentation:

| The syntax of the 'call' function is:
|
|      $(call VARIABLE,PARAM,PARAM,...)
|
| When 'make' expands this function, it assigns each PARAM to temporary
| variables '$(1)', '$(2)', etc.  The variable '$(0)' will contain
| VARIABLE.

Fix ALT bug 44561

See also:
https://github.com/osboot/make-initrd/commit/60afcd997affe150fe1153006ffcc1adac735710

check conditions of  make  for equality of variables with an empty value
instead of check definition.
A defined but empty variable under all these conditions results errors.

This will allow to add multiple lists to the X-Alterator-PackageList through
the character ";".
See also: https://bugzilla.altlinux.org/43186

This is following mkimage's approach;
better late than never.

`make clean' and `make distclean' use none of these,
no reason to spend extra forks, i/o and time.

NB: PKGDIR might be overridden now so that these functions
can be used within both metaprofile and generated profile
contexts; this isn't clean but I couldn't come up with
anything better so far.

These are alike to lists/groups ones.

Aimed at live images at first but should cover installers as well.

This has been brewing for quite some time and while the proper
implementation is considerably more complex (and hard to do)
looks like there's demand for the particular important use case,
namely LiveCDs for Russian users, so this code has been shared
with a few people before merge.

This function's got its argument order chosen for "aesthetical"
reason of $(2) following $(1) in the macros but the logical order
is exactly the opposite: we care for kernel flavour much more than
for module set (which is dependent upon it).

So while silent dropout of kernel-image if KFLAVOURS is set
but KMODULES is empty could be fixed by testing for $(2) only,
it looks like a good time to fix this discrepancy altogether.

As it happens, adding another architecture required almost no changes;
native 32-bit ppc build took only ARCH and a repo, qemu-ppc one still
has problems (/.host/entry hangs while unpacking setup for fakedata).

Proof of concept on a QS22:

  $ make ve/bare.tar.gz
  ** ARCH: ppc
  /bin/sh: rpmvercmp: command not found
  21:41:01 cleaning up
  21:41:03 initializing BUILDDIR: build/
  21:41:03 preparing distro config
  21:41:05 starting image build (coffee time)
  21:42:48 done (1:42)
  ** image: $TMP/out/bare-20120716-ppc.tar.gz [21M]

The only thing to be fixed was setarch(8) symlinks assumption
that is correct for x86 but not for ARM.

There's also some hasher(7) setup to be done:

  mkdir -p ~/.hasher
  echo >> ~/.hasher/config <<-EOF
  def_target=arm
  #cache_dir=$HOME/tmp	# depends on RAM/storage configuration
  EOF

...and of course apt(8) should be properly set up too.

An example PoC build on a CM-A510 board (tmpfs):

  $ make BRANDING=altlinux-centaurus ve/bare.tar.gz
  ** ARCH: arm
  18:10:45 initializing BUILDDIR: build/
  18:10:45 preparing distro config: build/distcfg.mk
  18:10:46 starting image build: tail -f build/build.log
  18:14:49 done (4:02)
  ** image: $TMP/out/bare-20120706-arm.tar.gz [23M]

An initial draft of it was done half a year ago but several tricky
thingies had kept the code from showing up as it was rather brittle
and incomplete.

This implementation involves quite a few changes all over the place
but finally works good enough for live and installer images.

Please pay attention to the versions of these packages:
- installer-feature-setup-plymouth (0.3.2-alt1+)
- branding-altlinux-sisyphus (20110706-alt2+ if used)
- plymouth (0.8.3-alt20.git20110406+)

See also:
- http://www.altlinux.org/Branding
- http://www.altlinux.org/Plymouth

This further refines the modular build by making
metadata being a clearly separated feature rather
than having to rely on runtime tests, and also by
moving the code which cares for kernel bits of base
installation (.base list) in a feature of its own.

There's more to it but let's get the ball rolling first.

As duly noted by glebfm@, branding issues need more attention
by now since only stage1/install2 got some of it so far in this
regard.  Hence the dedicated feature comes to the rescue
(well no, it doesn't actually mess with rescue!).

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...

If the build is (re-)run withing generated profile directory,
the makefiles no longer have ARCH passed by upstream -- the
upstream might be unreachable at that point indeed.

This is unfortunate but we should cope with that.

NB: might be revisited when architecture-specific packagelists emerge
since currently there's no difference in package lists so we can just
re-run the build for a different architecture but this might change...

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)

- image.in/functions.mk: rework kpackage()
  + it takes two arguments explicitly now: this adds some noise
    for "generic" invocations but is rather less messy with recently
    introduced STAGE1_KFLAVOUR (which in its turn is rather cleaner
    than messing with KFLAVOURS, especially since soemthing changed
    in presumably apt and we can't rely on kernel packages being
    installed in the order formed).
- BUILDDIR/DEBUG related fixes
  + Makefile: BUILDDIR initialization moved to distro.mk
- build.log += git info

- drop hardwired kernel flavour from pkglists
- today's std-ng lacks aufs, let's switch to un-def
- second assault at KERNEL_PACKAGES_REGEXP
- re-introduced kpackages (builds ok)

PS: base lists: switch to grub, add udev, cleanup

...along with obituary fixes.

- syslinux: menu.c32 works
- features: initial draft
  + memtest
- mv pkg/ pkg.in/
  + server-base: include openssh-blacklist by default
- mv isodata/ copy/
- README: changed to utf8, added an URL

- s/stage2/install2/g
- added pkg/lists
- initial README (ru_RU.KOI8-R)
- mkimage topdir is in image.in/, really (off-tree build)
  + initial bin/mktmpdir
  + BUILDDIR (works)
- s/cd/iso/
- drop --with-distro (considered harmful)