3 ms·

Thanks, I appreciate. > it looks like you're quoting a shell string like: That's not particularly a shell string, but a DEFINE; the rule is to declare them a

by Rochus 4y ago

Thanks, I appreciate. > it looks like you're quoting a shell string like: That's not particularly a shell string, but a DEFINE; the rule is to declare them as they are required by the compiler command line of a given platform. I can add a quoted_string() predeclared procedure if it helps. > have you tried talking with any cmake collaborators ... Something like BUSY as a frontend could be cool. No, I haven't; the BUSY spec is open source and available if need be, but for one part I would be very surprised if it was used just as is for the mentioned purpose, and on the other part I'm not sure whether it is a decent approach to add yet another layer to cmake (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, increasing the confusion we already have).

elcritch 4y ago
> That's not particularly a shell string, but a DEFINE Ah I am guessing that you are invoking the compiler using ‘sh’ (or cmd.exe on win). Otherwise you wouldn’t need the extra quotes. But then you should properly quote for the posix shell. Though you could exec the compiler but then you could probably keep it as a list. > I'm not sure whether it is a decent approach to add yet another layer to cmake Yah that’s the problem. Especially with large legacy build systems. > (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, Well I think they meant it’d built on the c++ layer. But it’d still need the old cmake language parser still.