Hello, I'm an embedded software developer. Most of our development is done with a cross-compiler, and is built using nmake makefiles. We also have a windows console cli application that talks to the target via USB. It was orignally written using the VS 6.0 IDE. Later, when we wanted to integrate building it into our automated build environment, we wrote makefiles (we did not use VS's makefile exporting feature), again using nmake. Instead of moving the dependency info into the makefiles, that was kept in the VS project files (.dsw and .dsp), and we currently use the msdev.exe command line builder in the makefiles. A macro was written to get VS to generate .dep files, which we use as part of the build process. So, VS6.0 isn't supported any more, so I'm looking into migrating away from it. The problem with doing the same thing but with later VS versions is that the ability for VS to generate the .dep files was removed in later versions. (M$ wants everyone to only use their IDE now, it seems.) The compiler, cl.exe, does not generate dependency info. We'd like to stick with the cl compiler for now because people here prefer the VS IDE for debugging. One option is to move the dependency info into the makefile (we can use gmake just as well as nmake) and continue to use cl.exe from the makefile. That could be just at ton of work. Could winelib be used to generate a gmake makefile that can be run from a Windows command prompt? (unfortunately cygwin is not part of our standard development environment) The code is C and C++. If so, how maintainable are the makefiles? We'd have to update the deps by hand. Can the winelib perl script be run on Windows with the ActiveState engine? Thanks, JeanneP PS: The reply-to address will bounce. Please post your response to this newsgroup. Thanks! _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users