Add Windows alternative to rm in Makefiles

[KeyWeeUsr]

There's a little bit different handling of file/folder removal on Windows and it makes MinGW/GCC fail with annoying errors forcing a user to compile by hand. The problem mostly isn't the first compile, rather the second (after the files are created).

Also, every bad error code kills make, therefore a user has to silence them if not successful, otherwise there will be no compilation and the make will just die because e.g. there already is a bin folder or something else.

The Makefiles however won't work with nmake.exe, which is MS alternative to GNU make, because the syntax is a little bit different, sadly.

Edit: Also it's good to mention that $(CC) returns (at least on Windows) just "cc", which maybe works somewhere, fails with gcc.exe and I believe it could fail on linux too.

[andres-asm]

Hmmm, rm and mkdir work perfectly fine in MSYS2 which is the most popular mingw environment nowadays.

On Mon, Feb 27, 2017, 11:19 AM Peter Badida [email protected] wrote:

There's a little bit different handling of file/folder removal on Windows and it makes MinGW/GCC fail with annoying errors forcing a user to compile by hand. The problem mostly isn't the first compile, rather the second (after the files are created).

Also, every bad error code kills make, therefore a user has to silence them if not successful, otherwise there will be no compilation and the make will just die because e.g. there already is a bin folder or something else.

You can view, comment on, or merge this pull request online at:

https://github.com/vurtun/nuklear/pull/358 Commit Summary

• Add Windows alternative to rm in Makefiles

File Changes

• M demo/allegro5/Makefile https://github.com/vurtun/nuklear/pull/358/files#diff-0 (5)
• M demo/glfw_opengl2/Makefile https://github.com/vurtun/nuklear/pull/358/files#diff-1 (5)
• M demo/glfw_opengl3/Makefile https://github.com/vurtun/nuklear/pull/358/files#diff-2 (5)
• M demo/sdl_opengl2/Makefile https://github.com/vurtun/nuklear/pull/358/files#diff-3 (5)
• M demo/sdl_opengl3/Makefile https://github.com/vurtun/nuklear/pull/358/files#diff-4 (5)

Patch Links:

• https://github.com/vurtun/nuklear/pull/358.patch
• https://github.com/vurtun/nuklear/pull/358.diff

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vurtun/nuklear/pull/358, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0IDpA-x0I9CKrWu_be_owm3eCooyks5rgveFgaJpZM4MNTy5 .

[KeyWeeUsr]

Yes, but that's bash, not Windows console (cmd.exe) which people can still use just fine with MinGW/GCC alone.

[andres-asm]

Hmmm I don't see you doing any sort of detection... you're just changing the commands if it's windows.

[KeyWeeUsr]

By detection you mean if it's Msys2 or CMD? If not, then the detection is already there - OS detection. On the other hand, there could be also a detection if the files exist, but that's handled with ||

[andres-asm]

Well, under msys2 and I guess cygwin... you have a full posix subsystem and as far as I can see this will break the makefiles for such environments.

Andres@PC-ANDRES1 MINGW64 ~/repositories/libretro-meta
$ uname -a
MINGW64_NT-10.0 PC-ANDRES1 2.6.0(0.304/5/3) 2016-09-07 20:45 x86_64 Msys

[KeyWeeUsr]

I tried to check even for msys, but this just overcomplicates the Makefiles and rather than that ugly piece of code the || method should be used as it's rather expected from a Windows user to use cmd.exe or Powershell over Msys + the "or" method falls back to rem, which does nothing (it's used for comments in batch).

On the other hand, feel free to close it if Msys/bash is the supported console :)

[dumblob]

@KeyWeeUsr I think there is a simple and reliable (even though really weird) solution - see e.g. the example in http://stackoverflow.com/a/10608327 :

ifneq (,$(findstring /cygdrive/,$(PATH)))
    UNAME := Cygwin
else
ifneq (,$(findstring WINDOWS,$(PATH)))
    UNAME := Windows
else
    UNAME := $(shell uname -s)
endif
endif

[andres-asm]

I do something like this:

ifeq ($(platform),)
	platform = unix
	ifeq ($(shell uname -a),)
		platform = win
	else ifneq ($(findstring Darwin,$(shell uname -a)),)
		platform = osx
	else ifneq ($(findstring MINGW,$(shell uname -a)),)
		platform = msys2
	endif
endif

and then use commands accordingly, I treat msys2 as any other posix environment and win as... well, Windows

[dumblob]

@fr500 are you sure you can reliably detect CMD environment that way? I.e. are all Windows versions with any SW installed on them nearly guaranteeing, that shell uname -a is a no operation? IMHO there are probably hundreds of different ways how you could execute shell uname -a and get a non-empty string on an unspecified Windows version with unspecified SW installed. And how about the Ubuntu userspace on Windows 10? That's neither "windows" nor "msys2/cygwin" nor "general POSIX" nor "pure Ubuntu" :wink:.

The solution I proposed should be quite bullet-proof as it assumes nobody would want to mangle with PATH in dangerous ways. I'm though not an expert on Windows, so please take my objections with a grain of salt.

[MrSapps]

Is it possible to check if ver exists, run it and check the returned output starts with "Microsoft Windows"? That should be a lot more reliable, IMO this is why CMake is much better than raw makefiles.

[dumblob]

Is it possible to check if ver exists, run it and check the returned output starts with "Microsoft Windows"?

Good point. I didn't think about "advanced" commands like ver systeminfo wmic ... which should actually do exactly what we want (see e.g. http://stackoverflow.com/questions/1792740/how-to-tell-what-version-of-windows-and-or-cmd-exe-a-batch-file-is-running-on ). And by the way, should there be any syntax issues, there is a good trick to use only the intersection of make and nmake functionality:

# \
!ifndef 0 # \
# nmake code here \
MV=move # \
RM=del # \
CP=copy # \
!else
# make code here
MV=mv -f
RM=rm -f
CP=cp -f
# \
!endif

(nmake should not recognize line continuations) For multiline commands the ; character should be used to make them singleline.

CMake is reliable in OS and environment detection, but has other flaws as discussed in https://github.com/vurtun/nuklear/pull/334 (actually I'm quite curious, whether a pull request, if any, for separate CMake files will be issued or rather a pull request with Makefiles compatible with both nmake and make).

[KeyWeeUsr]

@dumblob I've tried to implement it with findstring without Msys available, but it doesn't even recognize findstring and jumps right to the else part with my mingw (mingwpy). Have you tried to run such a Makefile with make(/mingw32-make) in a cmd.exe environment?

Or probably a better question - what's wrong with the current implementation? Does it break cygwin or msys? If not, I think it's safe as the command just falls into the void if anything happens along the way on Windows.

[dumblob]

@dumblob I've tried to implement it with findstring without Msys available, but it doesn't even recognize findstring and jumps right to the else part with my mingw (mingwpy).

That's suspicious. Did you run vcvarsall.bat or equivalent?

what's wrong with the current implementation? Does it break cygwin or msys?

It seems so, but I didn't test it (yep, I left Windows, but maybe I'll get back at some point). @fr500 could you quickly try it? It seems you're running a Windows machine.

[KeyWeeUsr]

Nope, just a clean cmd.exe with mingwpy binaries folder on my path and mingw32-make.exe. Cygwin or Msys report Windows as its platform too? Or can't they see the Windows specific programs?

[dumblob]

Nope, just a clean cmd.exe with mingwpy binaries folder on my path and mingw32-make.exe.

Worth trying to run vcvarsall.bat or architecture-specific equivalent. I'm curious about the results.

Cygwin or Msys report Windows as its platform too?

What do you mean by "reporting"? Content of some variables? Which ones? Result values of some applications? Which ones? And what is a platform in this case? An underlying operating system? Or the current environment? Or a version of some specific bundle of SW (e.g. MSVC)?

Such a general question might be answered only by a general answer, which is "Yes, Cygwin and Msys can report both - unix and windows platforms at different places under different conditions.".

Or can't they see the Windows specific programs?

Again a general answer - yes, they can see both. @fr500 could you please quickly try the examples above? Thanks.

[DmitryHetman]

Windows is ancient malware, why even support it?

[dumblob]

Windows 10 Latest release: 1703 (10.0.15063.138) (April 11, 2017; 2 days ago[2]) versus Ancient history spans 3200 BC - 632 AD. Also mind the non-existent overlap between the definition of malware and an operating system.

Let's leave trolling aside. The ultimate and definitive answer to your question is: because it's a personal decision of some people (including but not limited to Nuklear developers) which per se can't be argued and shall be fully respected by others in case it doesn't cause harm to them (which is definitely not the case of Nuklear nor anything related).