3 ms·

Oh cmake is full of so many gotchas. Dynamically typed specification languages are so painful. BUSY looks cool! Unfortunately my work projects rely on another

Oh cmake is full of so many gotchas. Dynamically typed specification languages are so painful. BUSY looks cool! Unfortunately my work projects rely on another big C++ project that has its own meta cmake layer. One thought, it looks like you're quoting a shell string like: ""NAPPGUI_BUILD_DIR=\"" + tostring(root_build_dir) + "\"" That'll break in annoying (possibly insecure) ways and is tedious to write the quotes. Perhaps you could add a 'quotedString' proc? Maybe: ""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir) Speaking of standards, have you tried talking with any cmake collaborators? I recall reading a post on HN discussing a possible new cmake frontend language. Something like BUSY as a frontend could be cool. BTW, here's my latest attempt to avoid dynamic configuration files by making a YAML like in Nim: https://github.com/elcritch/cimporter/blob/exper-interp/tests/rcutils_cimport.nim https://github.com/elcritch/cimporter/blob/exper-interp/test... It may look a bit complicated at first, but the underlying syntax rules are surprisingly simple and consistent. There are only a few small macros for convenience like the 'list' one that replaces array syntax. Best of all that means I get all the goodies of a statically typed language like type annotations from the LSP.

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.

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.