Using defines to specify an include path

Hi,

I am one of 6 developers working on this C++ project. We have recently
moved our GUI development to VC++ 7.1.xxxx (we're using several
versions, the lowest being 7.1.4322).

Were using common libraries and DLLs that part of the team develops.
These interdependencies are causing problems such as
"UnitConverter/include/UnitConverter.h" not found, or unable to find
"UnitConverter/lib/UnitConverted.lib". Each one of us has placed the
libraries and includes in the most logical place for that person. We
then specify that location using "Additional Include Dirs" in the
properties page for the project. But this only works partially. When I
open the project that developer X has been working on, I get errors
because he has placed our common libs and includes in a directory
different from mine.

My question is is there a better way to specify the root directory
where the .lib and .h's are?

In the Solaris world, we used to define a variable in the makefile. For
example, I share my libraries with others because we work on those, so
my root dir is a network drive:

f:/shared/VRT/beta1.6.2/.

under this there are several sub-projects each with an include and a
lib dir.

Developer X chooses to keep a more stable version of these libs on his
local D: drive under:

d:/VRT/1.6.0/.

this will have the sub-projects that I keep under my F: drive, except
an older version.

In Solaris using g++ and make, we'd have done this:

LIB_ROOT_DIR=d:/VRT/1.6.0/.
INCLUDEPATH=$LIB_ROOT_DIR/UnitConverter/include;$LIB_ROOT_DIR/CommonDefs/include
.... etc...
LIBPATH=$LIB_ROOT_DIR/UnitConverter/lib;$LIB_ROOT_DIR/CommonDefs/lib
.... etc...

Each developer can now easily change the LIB_ROOT_DIR to suit his PC's
configuration.

Can someone suggest a VC++ 7.1 equivalent?

Thank u!

.

Relevant Pages

  • Re: Why NOT to link using pragma comment (lib, libname)
    ... possibly third party libraries but for in house development, ... Update the libs and do a Rebuild All. ... There are 3rd party libraries, ... What if I am inhouse developer and project links against my library. ...
    (microsoft.public.vc.mfc)
  • Re: Are bad developer libraries the problem with M$ software?
    ... Rather than trying to take advantage of "secure libraries" on any given OS, ... developer of potential issues. ... And if designers of any language are going to ...
    (SecProg)
  • RE: Are bad developer libraries the problem with M$ software?
    ... >>I have never been able to fathom why compilers can't barf out better ... Secure Windows Initiative ... Are bad developer libraries the problem with M$ software? ...
    (SecProg)
  • Re: Q: ComVisible and CLSCompliant
    ... effort making it easy to interoperate between the two - but you don't have ... > from fully understanding this attribute's usage. ... >> libraries to be shared among different languages. ... >> C# developer but are creating libraries for other teams that are VB.NET ...
    (microsoft.public.dotnet.framework.clr)
  • Re: It Hurts When I Do This
    ... Being an old libraries guy (I used to do compiler run-time libraries before working on compilers themselves), I'd have suggested moving this code to a library routine - just pass it the descriptors of the LHS and RHS. ... But adding a library routine isn't without cost - it creates support headaches when users try to link objects with older libraries. ... I was a compiler developer for 15 years. ...
    (comp.lang.fortran)