Are you interested in BSD make?

[Curculigo]

Can you bring BSD make to w64devkit with the name bmake?

https://www.crufty.net/help/sjg/bmake.html

BTW, is it possible to use the www.crufty.net collection of *.mk files with w64devkit's GNU make?

[Peter0x44]

What would be the use case for this? Do you have projects that only work with BSD make?

[Curculigo]

Do you have projects that only work with BSD make?

No

What would be the use case for this?

BSD make has its own strengths. It will serve well as an alternative to GNU make.

[skeeto]

As far as I'm aware there's no Windows port for bmake. Because it involves lots of dynamic processes creation and management, it's a rather intensive systems programming problem and porting to an entirely different paradigm (Win32 versus unix) is non-trivial. However, w64dk is a curation, and even with a port I'm uninterested in supplying redundant tools. I disable the busybox-w32 make app because there's already GNU Make, and its vi app because there's already vim. I dropped NASM in part because it's redundant with GAS (it's also slow, and a poor fit for GNU toolchains, not supporting DWARF in win32/64 objects.) If there's such a port, I would like for it to be easy to build with w64dk, so that someone could build it for themselves if they needed or wanted it. That's why I like having support for Autoconf scripts in general (via src/profile).

[Curculigo]

There are various ports of bmake to Windows.

This was the one used by MSYS2 before they dropped the mingw-w64-bmake package:

https://github.com/arichardson/bmake

This is a newer effort:

https://github.com/VexedUXR/bmake

[Curculigo]

BTW, is it possible to use the www.crufty.net collection of *.mk files with w64devkit's GNU make?

[skeeto]

https://github.com/arichardson/bmake

That doesn't appear to be a Window port. By "Windows port" I don't mean "works on MSYS2" but is actually a native application.

https://github.com/VexedUXR/bmake

This one is an MSVC port, and appears to be viable. It's also pretty… strange. Like including windows.h by way of winsock2.h despite making no use of Winsock? It's also ASCII-only (boo!). I was able to build it in w64dk with a few tweaks:

--- a/make.h
+++ b/make.h
@@ -90,3 +90,2 @@
 #include <stdbool.h>
-#include <IntSafe.h>
 
@@ -94,4 +93,4 @@
 #define MAKE_ATTR_DEAD      __declspec(noreturn)
-#define MAKE_ATTR_PRINTFLIKE    _Printf_format_string_
-#define MAKE_ATTR_USE       _Check_return_
+#define MAKE_ATTR_PRINTFLIKE
+#define MAKE_ATTR_USE
 
@@ -1110,3 +1109,2 @@ UNCONST(const void *ptr)
 #define MAXPATHLEN  _MAX_PATH
-#define PATH_MAX    _MAX_PATH
 

Mingw-w64 doesn't have IntSafe.h, but this include is superfluous anyway. The second hunk are MSVC attributes. I could substitute equivalent GNU attributes, but simpler to delete them. The last hunk isn't strictly necessary, but the definition is redundant. Deleting it dismisses all the default warnings. Then a unity build (bmake.c):

#define MACHINE      "x86_64"
#define MAKE_VERSION "20240625"
typedef unsigned long DWORD;
#include "arch.c"
#include "buf.c"
#include "compat.c"
#include "cond.c"
#include "dir.c"
#include "dirname.c"
#include "for.c"
#include "hash.c"
#include "job.c"
#include "lst.c"
#include "main.c"
#include "make.c"
#include "make_malloc.c"
#include "message.c"
#include "meta.c"
#include "parse.c"
#include "str.c"
#include "stresep.c"
#include "strlcpy.c"
#include "suff.c"
#include "targ.c"
#include "trace.c"
#include "util.c"
#include "var.c"

Finally building is fast and trivial (~1.2s, half of which is parsing headers):

$ cc -o bmake.exe bmake.c

Honestly unity builds are by far the most sane way to build projects like this, and the original, upstream bmake ought to build like this, too. Splitting it up into 24 little translation units is unthinking, slavishly following silly old traditions for no reason. (Note: This applies to most uses of make.) Maybe this could be rolled into a w64dk port of bmake, forked from this project.

is it possible to use the www.crufty.net collection of *.mk files with w64devkit's GNU make?

Sorry, I really don't know, and I'm uninterested in figuring it out. As I was saying, most uses of make, especially stuff like that, are just silly and unnecessary.

[Curculigo]

https://github.com/arichardson/bmake

That doesn't appear to be a Window port. By "Windows port" I don't mean "works on MSYS2" but is actually a native application.

This is the PR to remove mingw-w64-bmake from MSYS2:

msys2/MINGW-packages#19802

You can have a look at the patches were used by MSYS2 to make the Windows port.

[Curculigo]

I'm looking forward to see your port of bmake. I want to know if it will survive bmake's test suite or not. bmake builds fine with the POSIX emulation layer of MSYS2, but the resulted bmake has never survived the test suite.