Thought I'd write this down since I have a bad history of forgetting useful changes to build/ (such as that variable idea Jeff came up with in Oldenburg). ths and I were talking about how to better support 2.6 kernels and other stuff in build/ and this is the result. There are two phases: Phase 1: The depths of the various subdirectories of build/config/ will lose any particular implicit meaning. Subdirectories will be able to be made arbitrarily deep with any names we'd like. The Makefile will construct targets from these like it does now, and recurse through them for full builds. So instead of the current build/config/<arch>/[subarch]/[medium]/[flavour]/leaf.cfg, we'll be able to add new subdirs and/or reassange things as desired. Although we'll probably keep a similar overall structure by convention. This will let us add 2.6 directories, 2.4 directories if we want to stop special casing it, and other useful subdirectories. The tree for i386 will change to look something like this: cdrom el-torito 2.6 2.4 isolinux 2.6 2.4 floppy access root boot cd-drivers net-drivers root boot cd-drivers net-drivers hd-media 2.4 2.6 monolithic 2.4 2.6 netboot 2.4 2.6 We could drop the EXTRANAME stuff since we can arrange things in config/ to exactly match how we want them to look in dest/. .cfg files in these directories will inherit from files in the parent directories as before. There will probably be a CHILDREN = setting in the parent .cfg files to make the Makefile recurse into the children. Or it might just recurse automatically, dunno. Making the Makefile recurse through these directories is the big black magic part of this that I have no idea how to do. :-) Since the MEDIA and SUBARCH variables can no longer be intuited from subdirectories in the config tree, they will instead be set explicitly in the .cfg files. For phase 1, we'll still use TYPE, or possibly begin using MEDIA, to select which pkg-list file to use to build an image. Phase 2: Once phase 1 is complete, we can look into reorganising the pkg-lists files to match. In fact, ths wants to put them directly into config/, so an image will be defined by a pair of .cfg and .lst files in a subdir of config/. Package lists for images would then be built up by walking the tree to a leaf and combining all the .lst files enroute. Notice that this, combined with the 2.4 and 2.6 subdirs above, will let us do away with the pkg-lists/kernel-specific hack and may well also obsolete the need to list kernel major versions in brackets inside pkg-list files. Instead just put the 2.4 specific stuff in the 2.4 directory, the 2.6 stuff in 2.6, and the common stuff in their parent. One question is where the non-arch-specific pkg-lists files go. I'm not sure if cluttering config/ with base.lst, kernel.lst, cdrom.lst, netboot.lst, etc would be good. We might put them in a special subdirectory and use the #include mechanism to pull them in or something like that. -- see shy jo
Attachment:
signature.asc
Description: Digital signature