On felix-language, skaller wrote: > The thing is, the whole *design* principle of make is utterly > wrong... > <snip> > Target (goal) driven building is WRONG. It starts to fail > for even trivial projects in C, it fails completely and > utterly for anything non-C or even moderate sized or with > any kind of commercial objectives.
Erick had a great idea about composable builders before. We really need to start talking about the actual design. We already talked about the configuration-adaptation step--you (skaller) noted that the only way to conduct resource-discovery boils down to autoconf-style (I think you meant functions, headers, compiler implementation and not discovering the correct way to invoke egrep). A truly convenient configuration system should "know" everything about the architecture (or discover it--robust, built in search) and you should only have to query the build system; for some architectures it might offer alternatives (Windows in particular) but that would require more maintenance on our part (a community offering small, easy-to-write plugins would help). The adaptation part should be different than C; limit the use of the C preprocessor for selecting code (I say this from GHC-land which is suffers greatly from it). For languages without a preprocessor you really have to sponge off CPP, which is ugly. Interscript may help fill this gap but you (skaller) noted on the ghc-list how interscript takes over the build system. As a rule, the build system and code should be separate; no one is going to adopt a new build system if they have to adapt their code to it. I am not sure what the alternatives are but I am not out of ideas here--they are just too grandiose to talk about at this stage. At the basic level it must also support a pre-set configuration setup for known architectures. This is Jam-style and it works; it is also the only way to do industrial-grade cross-compiling. The build system may support a package system but developer-wise the build system should primarily support flexible development: it should offer the same flexibility for spot-building and testing that you get from an IDE. With xcodebuild I can set multiple targets to build and build them separately or all at once. Well, to build them all at once I do have to package the targets together or create dependancies--that is a fundamental problem of organisation. What I mean is that the convenience of a well-designed Makefile system is that you should be able to type something like 'make test1' and that will be build separate from anything else. You should not have to 'build' the entire package in order to rebuild a single test program. That is a serious drawback to Cmake and similar programs. The whole system should be manageable at separate levels. With Make there is only one level, really, and everything is done in Make code. A better system would have a top-level setup (Erick's composable system here) and a completely separate lower-level system for determining source files and variants. The system must have a good level of automation built in and the API should be adaptable to understand different languages. The automation provide things such as: the capability to do an automatic search of source directories and allow the developer to simply organise the code; an automatic search for system resources (including program locations) and the developer should be able to simply ask the build system for the requirements. The API should allow you to plug in another language compiler (possibly as an external tool but also as a 'builtin', like Jam's builtin understanding of C)--this implies that the language we use to build it should have a minimal C api. Another type of automation is dependancy tracking (I mentioned directed graphs before--this is a graph reduction problem) and for usability the system should be able to detect and guide a developer through potential problems before the build, i.e., circular dependancies, things out of dependancy order, potential conflicts., etc. It might be interactive. Well, I hope that is a start. I can prototype something to firm things up sometime soon (I hope). I'm sure you both have great ideas kicking around; all we have to do is organise them into a project document and start a prototype. Cheers, Pete ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
