busybox-w32
busybox-w32 copied to clipboard
rmyorston
include gMake applet
It's a far stretch - but including gMake would make development on windows machines fairly powerful. I think it could be leveraged with Eclipse and NetBeans CND plugin - as well as commercial packages like IAR depending on licensing.
I can see the value in this, though it's not something I'd wish to implement myself.
Upstream busybox doesn't have a make implementation, do they? There is a win32 mingw port of gmake around somewhere, though it handles paths a little differently than msys (1 or 2) make or cygwin make. It can build simple things but isn't perfectly compatible.
No, there's no make in upstream busybox. I prefer not to stray too far from upstream and don't know if they'd entertain a make applet. It's not really something most people need in their router. That needn't be a showstopper, though.
Compatibility would be an issue. Implementing all of GNU make wouldn't fit the busybox philosophy. I can imagine people getting peeved if they throw a random makefile at busybox make and it doesn't work. With shell scripts you can always say "You're doing it wrong: use POSIX" and they'll grudgingly accept that. POSIX make doesn't have the same traction.
I agree. Bit of an unfortunate reality, but there you have it. Busybox is aiming at coreutils and a (posix) shell, and not much more. There are other larger projects out there aiming for a more complete unix-like development environment. I'm keeping my eye on the progress of http://midipix.org/ as a recent addition to that list.
If it is a problem including it inside BusyBox, would it be possible to have it as separate executable?
The other versions for Windows doesn't seem to be maintained.
A separate executable would be a different project, though, not busybox-w32.
I haven't closed this issue because I have no strong objection to including a make applet in busybox-w32, even if upstream BusyBox didn't want it. Clearly there is a demand for it.
I don't plan on implementing it myself, though. But I will consider pull requests
OK, it took a while but busybox-w32 now has an experimental make applet.
It isn't GNU make. Instead it's based on my public domain POSIX make. All the features listed for the default build are available, including several extensions that are compatible with GNU make.
I haven't submitted this upstream (yet). Let's see how it goes here first.
The most recent prerelease binaries, PRE-4726 or above, have the new applet enabled.
I just noticed 67a630e. Very interesting! In my own distribution I plan to keep GNU Make as make, but I may include your Make renamed to pdpmake.
Since this issue has been kept open, let me add that I absolutely adore your nice little pdpmake in BB! It's a wet dream for developers like me. (Also love @skeetoo's work, naturally.)
For a try yesterday I put together a BB/pdpmake ("strictly non-POSIX") makefile that builds small C/C++ (mixed) source trees (with MSVC), into a separate output tree, with almost no configuration (especially without listing any sources, which is a hard requirement for any build solution I'm willing to consider), in under 80 lines (~30 of it comments), and apart from the facilities of (the surprisingly capable) pdpmake it only uses some other BB built-ins (like find, cp, mkdir; the usual).
It's sketchy, dodgy, kludgy (there are still limitations), but the sheer fact that it can be done at all (the same even with NMAKE can be very involved, and still quite brittle) means I may no longer need to keep an instance of gnumake.exe in the back pocket of my projects (which could just be the case for the OP, too).
I have no words for how amazing and refreshing this is (and BB-w32 in general). w64devkit with BB-w32 is the sexiest C/C++ Windows dev. env. in existence today.
It's sketchy, dodgy, kludgy (there are still limitations) ...
Well, turns out, with a ridiculously light change to pdpmake, it could be made very not sketchy, dodgy, kludgy any more. (E.g. no need to "secretly" copy/update the entire source tree into the build output dir now, just straightforward make stuff (almost) as usual.)
It covers a big chunk of the "VPATH usability vacuum" (e.g. rmyorston/pdpmake#29).
Anyway, food for thought.