> > The main difference that you seem to be pointing out is tokenization. For > the vast majority of file names you could just make your lua code use > double quotes, and insert the arguments programmatically. You could also > make a shim around define rule that uses double quotes on windows and > single quotes on Linux/Darwin, similar to the way that path joining > utilities have to use different slashes if you're referencing anything > outside of your directory. >
I do this already, but it's ugly: with tables, it's clear which argument is which, no matter what characters they contain, but with a plain string one has to rely on special characters to delimit parts and escape sequences. Tables are one level lower than strings, and it's much easier to "go up" than "down": abstracting and "going down" has the risk of making mistakes because it involves parsing, whereas the rules followed when "going up" are much more clear). As for slashes, I believe '/' works just fine on Windows too, but it could be cygwin… If paths aren't handled by Tup but are system-dependent, directory hierarchies could be another candidate for abstraction with tables on the Lua side. > […] windows uses CreateProcessW (see Pat's link). That call does not allow > a pretokenized string. Doing a little investigation reveals that the > problem is not even with cmd.exe but with with windows itself. So, at best > the windows side of tup would have to guess as to how to turn your table > into a windows command string. > Oh, I didn't know that. But even then, wouldn't it be better to put such logic in one centralized place, instead of duplicating it in each project? What problems could it pose that Tup joined"ed commandlines itself in Windows? -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
