3

I'm porting an application to MacOS X - but the original developer's build system uses NMAKE, and ideally they'd like to keep it instead of switching to a new one.

I've managed to get NMAKE running under OSX using wine (built using MacPorts) and added Objective C support to the build files, and created a Unix-linked PE wrapper 'run.exe' which wine can load but uses POSIX to call back into things like gcc and ld, as is described on various places online as a means of escaping out of wine back into Unix.

However, I'm having a few specific issues. They're minor enough that I can get on with the port, but it does mean I need to run builds a few times sometimes, because of timing.

Basically, when wine.exe calls back into the shell and thus gcc, the link between child processes seems to be broken. gcc and ld will never return an error code even on failure, because they can't get the exit code from their spawned children. ar will actually print out it can't find its child and return immediately, causing problems when ld tries to link object files to libraries that are still being put together.

Has anyone else tried anything similar and seen the same problem, on OSX or elsewhere? Is there an obvious solution?

electric-monk
  • 108
  • 8
  • ease your life, switch to something like CMake? or maintain separate build systems: xcode, visual studio, autotools or raw gnu makefiles -- to me what you're doing isn't future proof – Gregory Pakosz Aug 14 '10 at 11:58
  • There is the option of switching to a completely new build system, but obviously they want something that will work on both Windows and OSX, strongly against maintaining multiple systems. They did also strongly prefer sticking with nmake, as that's what they're used to :) I think if it weren't for the wine child process issue this would be an entirely future proof solution, though. – electric-monk Aug 15 '10 at 22:36

2 Answers2

1

The Microsoft .NET Rotor (SSCLI) project includes source code, intended to be build on OSX and elsewhere. The Rotor source code includes the source code to NMake. So get Rotor working, then use it's Nmake. Even if you prefer to continue to use your Wine-based Nmake, you could probably learn from Rotor's use of Nmake on Unix, it's use of Gcc, etc.

Paul R
  • 208,748
  • 37
  • 389
  • 560
Lee Fisher
  • 36
  • 2
  • This is perfect, thanks! After a lot of hacking around the slightly aging code, tweaking code and circumventing Microsoft's build scripts, I now have a shiny nmake binary that is native to OSX and works perfectly. Other than all the stuff I had to fix and the totally broken build, Microsoft did a pretty good job of wrapping OSX (and Unix). – electric-monk Jan 22 '11 at 02:42
  • Glad it helped. You should post your changes somewhere, so others can benefit from your work! – Lee Fisher Aug 07 '15 at 21:37
0

If there is nothing that odd / inconsistent about the original developers build system, could you write an automatic conversion of their make files back into Unix make, and keep your builds 'native'?

(Builds being fraught enough anyway, without extra complications)

JulesLt
  • 1,765
  • 10
  • 9
  • I've considered the idea of making a convertor, but I was concerned it could actually become a major bit of work in itself - especially when the nmake-in-wine solution is *almost* working perfectly - nmake even seems to handle Unix-style paths without a second thought, it's just this weird wine issue. – electric-monk Aug 15 '10 at 22:34