Robert Clausecker <fuz%fuz.su@localhost> writes: > Schilytools ships with its own make implementation (smake) but has > support for building with other makes. Unfortunately bmake is not > supported. Before the main author Jörg Schilling died, he was working > on bmake support but eventually concluded that it is not possible. > This is because the build system makes intensive use of a feature of > other makes where if an include file is not found, make stops parsing > the makefile at this point, tries to build the include file and if > that succeeds, continues parsing with the newly generated file. Rinse > and repeat until all include files have been generated. > > This feature is vital to the way the build system works. For example, > it is used to run a configure script generating further makefile > fragments or to generate missing symbolic links. What does "include file is not found" mean? Do you mean "foo.h is a dependency of bar.c, but foo.h does not exist, and there is no rule to make foo.h?" If so, why aren't there rules? If not, please clarify. From the pkgsrc viewpoint, using gmake as a build tool is not a big deal. Many things do, so it gets built anyway on most systems. I feel that avoiding a gmake tool depends for schilytools is not a tremendous gain, compared to the effort, possible architectural issues, and future maintenance involved in adding a feature (that I am pretty sure is not mandated by POSIX) into bmake. (FWIW, not much, this is the first time I've encountered this feature.)
Attachment:
signature.asc
Description: PGP signature