From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Bengt Kleberg Message-ID: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: , <406D7906.3030701@swtch.com> Subject: Re: [9fans] acme, rio workalike available in plan 9 ports Date: Mon, 19 Apr 2004 10:04:44 +0000 Topicbox-Message-UUID: 5eef4406-eacd-11e9-9e20-41e7f4b1d025 Russ Cox wrote: > >> i would conjecture that we have not one, but two ''mk''. >> one from mk-20040301.tgz that is of interest to a unix user that wants >> a new ''make'', but is not interested in plan9. this mk does not need >> to use ''rc''. > > > > these are the same mk, built from the same sources. you are ofcourse correct. i was beeing very fuzzy in my writing here. i was not thinking of ''mk, the implementation'', but more of ''mk, the program the user interfaces too''. >> the other ''mk'' is the one in plan9-20040321.tar.gz. this mk will be >> used by someone interested in plan9. i belive that this mk should use >> rc. if rc is not stable enough it should be made stable enough. > > > > in an ideal world, where there is more time for such things. > it is slowly becoming stable enough. there is some funniness > with process groups and backgrounded processes and interrupt > notes that i have yet to work out, but otherwise it is now fine. is it ok to interpret this to mean that rc is good enough to be used as the shell in mk? >> since it is never a good idea to have different commands with the same >> name (provided we have the same context. in this case unix) i suggest >> that one of the two mk are renamed. the one to rename, imho, is the >> one that uses sh. possible names would be: smk, umk (or mks, mku). > > > > it's the same tool, just using a different shell. renaming it seems > quite weird. > should it read umkfile too? the last thing we need is for mk to bifurcate > into odd variants just like make has. i fully agree. it was this kind of problem that made me raise the question in the first place. i think mk using sh is an odd variant. i think of mk as using rc. this is also why i decided it would be best (for me) to penalise old mk-on-unix users (the ones already using sh). > there is historical precedent for mk on unix using sh. i'm not claiming it > should, just that it's not obviously wrong. > > there are non-plan 9 users who use mk on unix and expect it to use sh. > telling them that all of a sudden they have to rename their mkfiles and > start typing umk is odd. this is true. however, how large a user base is neccessary to stop progress in the name of backwards compatibility? > i have some ideas about how to solve the problem without splitting mk, > but at the moment it's not very high on my list. the number of recipes > i write that aren't simultaneously valid rc and valid sh is very small. a kitchen sink approach would be for mk to recognise sh or rc recipes, and handle them accordingly. another solution would be for mk to check for $PLAN9, and then use rc but mostly this would mean mkfiles that sometimes work, and sometimes does not work. we could call mk-with-rc for rmk, mk9, ... or use ''mk -r[c]''. i will use mk instead of make, even if you decide to keep sh. bengt