Windows routinely uses pathnames with spaces in them, in particular "Program Files." Mac does this pretty often as well. That's a bugaboo for Autotools because of the near-constant use of variable substitution, as well as the fact that Make uses spaces to separate filenames. The scripts may attempt to execute a file named "C:\Program" with a parameter like "Files\actual_program_name" because of not knowing those are two parts of the same string. Users of Autotools have been griping about it for many years, and have not been getting much sympathy from the maintainers of Autotools, who consider Windows to be fundamentally broken and not really worth supporting.
It is probably not possible nor worthwhile to attempt to solve this external problem completely within the Tsukurimashou Project. GNU should clean up the mess they created themselves. However, in at least some common cases it may be possible to reduce the harm by minor changes to the Tsukurimashou build scripts. See for instance https://gist.github.com/jtanx/612bd6c629a76e1aa977 . Quoting the variable substitutions allows the Tsukurimashou build to invoke system-installed software that is installed in paths containing spaces. Allowing Tsukurimashou to build with its own sources or installation targets in such directories may be much harder and is probably not worth it.
There's some danger of "give an inch and they'll take a mile" - if Tsukurimashou EVER accepts paths with spaces in them, then users may expect it to ALWAYS accept such paths, and really doing that (because it's a fundamental problem with Autotools in general) is a gnu too hairy to shave. But maybe careful documentation could help here.
mskala 
Tsukurimashou Font Family and IDSgrep
Windows routinely uses pathnames with spaces in them, in particular "Program Files." Mac does this pretty often as well. That's a bugaboo for Autotools because of the near-constant use of variable substitution, as well as the fact that Make uses spaces to separate filenames. The scripts may attempt to execute a file named "C:\Program" with a parameter like "Files\actual_program_name" because of not knowing those are two parts of the same string. Users of Autotools have been griping about it for many years, and have not been getting much sympathy from the maintainers of Autotools, who consider Windows to be fundamentally broken and not really worth supporting.
It is probably not possible nor worthwhile to attempt to solve this external problem completely within the Tsukurimashou Project. GNU should clean up the mess they created themselves. However, in at least some common cases it may be possible to reduce the harm by minor changes to the Tsukurimashou build scripts. See for instance https://gist.github.com/jtanx/612bd6c629a76e1aa977 . Quoting the variable substitutions allows the Tsukurimashou build to invoke system-installed software that is installed in paths containing spaces. Allowing Tsukurimashou to build with its own sources or installation targets in such directories may be much harder and is probably not worth it.
There's some danger of "give an inch and they'll take a mile" - if Tsukurimashou EVER accepts paths with spaces in them, then users may expect it to ALWAYS accept such paths, and really doing that (because it's a fundamental problem with Autotools in general) is a gnu too hairy to shave. But maybe careful documentation could help here.