Hello all, Here is a design change proposal about the /elkscmd configuration & build process. Today the main build script is generating several Minix images for the target : comb360, full3, etc. Some other scripts from George also generate some FAT images, but not in the main build workflow. When building one image, the user land stuff is gathered from the various subdirs of /elkscmd, based on 5 configuration sets that select the commands to be included in that image : smin_rfs, min_rfs, rfs, max_rfs and net_rfs (this latest one is quite buggy). One big issue is that the definitions of these sets are scattered over all the Makefiles : each Makefile specifies what are the sets that include the related command. So it is hard to figure out the overall image content without scanning all the Makefiles. Thus we frequently hit the image size limit if not taking care of the whole. Another issue is that it is hard for any user to customize the set of commands in a given image, without hacking the Makefiles. And last but not least, some commands and startup scripts are tightly coupled to the configuration of the kernel. For example, network applets should not be included in the image if the networking is not supported in the kernel. So the proposal is not to build all the images, but to allow the user to select one image format (FD360, FD720, FD1440, HD, custom one, etc), and to select the commands to be included, with conditions from the kernel configuration. This is actually how BuildRoot is configured. The existing configuration script has already been extended to the whole source tree for that purpose in a previous PR, only remains to rework the build process in /elkscmd. The negative impact is that it would be more difficult to build all the possible images in one pass (even it could be scripted), but I wonder why a particular user would be interested in building more than one image at a time ? One interesting impact would be the ability to select all the commands and build a big test image, in order to check no build regression for the whole source tree. Any feedback on this proposal is welcome before I submit the corresponding PR. MFLD -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
