40 ms·

> The big downside of Make, alas, is Windows compatibility. GNU Make works fine on Windows. The sources come with a vcproj to build it natively, or you get it

by deng 7y ago

> The big downside of Make, alas, is Windows compatibility. GNU Make works fine on Windows. The sources come with a vcproj to build it natively, or you get it from ezwinports. At my dayjob, we have a pretty complicated build with GNU Make for cross-compiling our application to Arm and PowerPC, and it works on Windows, even with special Guile scripts to reduce the number of shell calls which are extremely slow on Windows.

Const-me 7y ago
Most popular folder on Windows is "My documents", it has a space at least in some Windows versions. Make doesn't support such paths: http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712 VBScript works better on Windows, IMO. Also works out of the box on all Windows versions since at least 2000 (on Win9x it was shipped with IE).
- pinum 7y ago
  >Most popular folder on Windows is "My documents" Not really... not since XP, anyway. Unless you have a space in your username (which is a terrible idea for many other reasons), your "Documents" path is C:\Users\JohnSmith\Documents. "Program Files" is pretty much the only important path which is likely to have spaces, and your makefiles (hopefully!) don't need to touch that.
  - Const-me 7y ago
    On Windows, it's not up to me to decide where users will keep my stuff, and where it will work. Users decide. For a software to work fine on Windows, it must support spaces in files and paths. Also Unicode in files and paths. VBScript does, GNU Make doesn't. > which is a terrible idea for many other reasons If you use make to setup stuff, it's very possible you'll need to access "c:\Users\All Users" which does contain space in username. Also "c:\Program Files (x86)\Common Files" which contain more than one.
    - WhiteOwlLion 7y ago
      You can try the 8.3 convention, DOCUME~1 Documents or <SYMLINKD> ALLUSE~1 All Users [C:\ProgramData]
- deng 7y ago
  > Make doesn't support such paths That is entirely correct and really the most glaring downside of Make. In my opinion: If you have spaces in your dependency names, just stay away from Make as far as possible.
- enesunal 7y ago
  You wouldn't install Visual Studio 6 to XP easily; since it wasn't support spaces in "Program Files" directory :)
  - Const-me 7y ago
    Long paths were introduced in Windows NT in 1993, VC6 released in 1998. I’ve just installed Visual C++ 6.0 Professional on a WinXP VmWare machine. Took less than a minute, BTW — modern SSDs are awesome. The default installation path under program files also contain spaces, it’s "C:\Program Files\Microsoft Visual Studio\VC98" BTW, they have a bug even on the very first welcome screen: http://const.me/tmp/vc6.png http://const.me/tmp/vc6.png
voltagex_ 7y ago
You'll have WSL/WSL2 to work with, too. If not make, then CMake is now supported in Visual Studio (2017/2019) and works well. >ezwinports Interesting, hadn't run into this before. What's the advantage over MSYS2?
- deng 7y ago
  Eli is one the few free software veterans who exclusively works on Windows. His ports are excellent and native Windows binaries wherever possible ("native" meaning: no MSYS at all). It's not that "native" is always better, but it is good to have the choice. Especially w.r.t. GNU Make, I found the MSYS version to be very hard to reason with, since the additional MSYS path conversion makes things even more complicated than it already is...

by deng 7y ago

Const-me 7y ago

Most popular folder on Windows is "My documents", it has a space at least in some Windows versions. Make doesn't support such paths: http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712 VBScript works better on Windows, IMO. Also works out of the box on all Windows versions since at least 2000 (on Win9x it was shipped with IE).

pinum 7y ago
>Most popular folder on Windows is "My documents" Not really... not since XP, anyway. Unless you have a space in your username (which is a terrible idea for many other reasons), your "Documents" path is C:\Users\JohnSmith\Documents. "Program Files" is pretty much the only important path which is likely to have spaces, and your makefiles (hopefully!) don't need to touch that.
- Const-me 7y ago
  On Windows, it's not up to me to decide where users will keep my stuff, and where it will work. Users decide. For a software to work fine on Windows, it must support spaces in files and paths. Also Unicode in files and paths. VBScript does, GNU Make doesn't. > which is a terrible idea for many other reasons If you use make to setup stuff, it's very possible you'll need to access "c:\Users\All Users" which does contain space in username. Also "c:\Program Files (x86)\Common Files" which contain more than one.
  - WhiteOwlLion 7y ago
    You can try the 8.3 convention, DOCUME~1 Documents or <SYMLINKD> ALLUSE~1 All Users [C:\ProgramData]
deng 7y ago
> Make doesn't support such paths That is entirely correct and really the most glaring downside of Make. In my opinion: If you have spaces in your dependency names, just stay away from Make as far as possible.
enesunal 7y ago
You wouldn't install Visual Studio 6 to XP easily; since it wasn't support spaces in "Program Files" directory :)
- Const-me 7y ago
  Long paths were introduced in Windows NT in 1993, VC6 released in 1998. I’ve just installed Visual C++ 6.0 Professional on a WinXP VmWare machine. Took less than a minute, BTW — modern SSDs are awesome. The default installation path under program files also contain spaces, it’s "C:\Program Files\Microsoft Visual Studio\VC98" BTW, they have a bug even on the very first welcome screen: http://const.me/tmp/vc6.png http://const.me/tmp/vc6.png

voltagex_ 7y ago

You'll have WSL/WSL2 to work with, too. If not make, then CMake is now supported in Visual Studio (2017/2019) and works well. >ezwinports Interesting, hadn't run into this before. What's the advantage over MSYS2?

deng 7y ago
Eli is one the few free software veterans who exclusively works on Windows. His ports are excellent and native Windows binaries wherever possible ("native" meaning: no MSYS at all). It's not that "native" is always better, but it is good to have the choice. Especially w.r.t. GNU Make, I found the MSYS version to be very hard to reason with, since the additional MSYS path conversion makes things even more complicated than it already is...