mkimage-profiles/lib/sugar.mk

# this makefile contains some syntactic sugar for the toplevel one

# strip prefix
config/with/%: %; @:

# just map to specific features
config/like/%: use/build-%; @:

# map and preconfigure
config/pack/%: use/pack/%
	@$(call set,IMAGE_TYPE,$*)

# just preconfigure
config/name/%:
	@$(call set,IMAGE_NAME,$*)

# request particular image subprofile inclusion
sub/%:
	@$(call add,SUBPROFILES,$(@:sub/%=%))

# the final thing will pull the rest in
build: postclean; @:
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-10-06 12:46:31 +04:00			`# this makefile contains some syntactic sugar for the toplevel one`

			`# strip prefix`
			`config/with/%: %; @:`

			`# just map to specific features`
			`config/like/%: use/build-%; @:`

			`# map and preconfigure`
			`config/pack/%: use/pack/%`
			`@$(call set,IMAGE_TYPE,$*)`

			`# just preconfigure`
			`config/name/%:`
			`@$(call set,IMAGE_NAME,$*)`
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... 2011-12-30 14:46:58 +04:00
initial rootfs subprofile and services feature This subprofile is akin to THE_* variables family: the configuration bits and script hooks sitting there influence whatever chroot is declared to be the user facing one in the end, whether it comes from vm image or live subprofile. The services feature ought to be a changeset of its own which would be based on rootfs and become the base for ve/vm changes but I chose to just do it atomically; some pre-existing duplicates are pruned now. 2013-05-28 12:51:36 +04:00			`# request particular image subprofile inclusion`
			`sub/%:`
			`@$(call add,SUBPROFILES,$(@:sub/%=%))`

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... 2011-12-30 14:46:58 +04:00			`# the final thing will pull the rest in`
plant SHELL beacons into all config-forming rules As noted in doc/assumptions.txt, the SHELL based target tracing only works for rules with recipes, even empty but present ones. The simplest thing to do is hooking "; @:" onto the rule's tail (one-liner with a non-printing shell builting "true" command). 2012-03-19 15:25:31 +04:00			`build: postclean; @:`