tags:

views:

42

answers:

1

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?

A: 

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
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.