Most of my projects are normal Win32 projects and VAX works fine with these. However, I do have a few NT driver projects for which I use VS.Net, but driver builds can only be integrated into VS as "Makefile" projects.
Obviously for "makefile" projects there is no "project include directory" information in the .vcproj file that can be used to help VAX find the include files. But could we have a new optional VAX project file which I could edit with a text editor? If such a file exists next to the vcproj file, it could specify additional (or alternative) include paths.
Or is there another mechanism that I could use to achieve this?
I use lots of makefile projects, and I always just add all the project files to the VS project as per usual. That way VA works with them fine, and VS doesn't try to build them because it knows it's using a makefile project.
Is there any reason why you couldn't just add all the files to the real vcproj?
quote:Is there any reason why you couldn't just add all the files to the real vcproj
Mainly because I am pulling in quite a few header files indirectly from a number of shared directories. I *could* discover them all manually and set up the project that way. But I guess in practise, I just wouldn't bother. A big plus point for me in using VAX is to avoid error-prone manual processes like that.
I'll have one more attempt at making the case for something before I concede defeat ...
I agree wholeheartedly that any *source* files used by the makefile can (and should) be added as part of the project. This is what I do. My concern is the INCLUDE directories.
The assorted source files include (directly and indirectly) quite a number of different include files. I would not want to have to identify each include file and maintain an up-to-date list in the project. The Makefile (actually the "Sources" file) contains a single INCLUDES definition from which the build finds all the required files. But VAX can't find this definition.
An alternative "solution" would be to add my own project-specific directory to the "Custom" C/C++ Directories list, but that list is global across all projects and so might not be very appropriate in other contexts.
Topic Locked
Posted - Apr 16 2004 : 08:08:59 AM
