>> of course calling cl.exe, link.exe and all the stuff directly _is_ an option. >> But, sometimes, when you use such tool as Visual Studio, you want to have >> projects (.vcproj) and solution files (.sln) configured so that you can >> build-on-request during development from inside the VS's IDE (or your boss >> wants, or your fellow developer does, ...). >> >> So, these VS files contain (mostly) all information concerning build issues >> of >> given solution. But it's only devenv who knows how to deal with it. > > Okay, but then why invoke devenv from Make?
Hmm, I don't quite follow. Suppose I have large heterogenous project (I do have), which I want to build with make, due to its numerous features and abilities. However, the project includes several solutions being developped and built under VS. How can I achieve the goal of complete build process for everything? Got to invoke devenv from make those several times. Of course, among other defects, there's loss of dependency control between make and devenv, long build time, problem with the very invocation as it was discussed here etc. But: * I don't want to rewrite devenv's project files with make, as I tend not to repeat myself; * building the whole just within devenv is impossible - it's not that kind of tool at all. What was your idea, then? >> BTW, Previous versions of VS used to have feature of generating makefile >> (nmakish one) given solution file. But that feature disappeared many years >> ago... > > Really? I use VS 6 sometimes, and the feature is still there. What > version dropped it? Between VS6 and VS7 (7.0), so it happened quite long ago. Since VS6 features (among others) poor compiler and poor implementation of STL, sticking by the old version due to nmakefile generation abilities is actually not an option. Regards, nosek _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
