Re: Conditional compilation

Discussion in 'C++' started by Tobias Müller, Dec 26, 2012.

  1. Giuliano Bertoletti <> wrote:
    > Hello,
    >
    > this is a rather platform specific issue that might however have a
    > general solution (I hope).
    >
    > I need to perform a conditional compilation of a C++ source code
    > depending on which host I'm compiling it on.
    >
    > for example:
    >
    > #if <compiling on host1>
    > #import <pathA/file>
    > #elseif <compiling on host2>
    > #import <pathB/file>
    > #else
    > ... // error! unknown host
    > #endif
    >
    > As you can easily see the "#import" directive inside each block is MSVC++
    > specific, however I cannot avoid using it and most importantly I need
    > conditional compilation because "pathA" and "pathB" differs depending on
    > extenal factors like the OS type (32 or 64bit) or more generally on the host.
    >
    > What I'm wondering is if there's some way to set an extern environment
    > variabile and have the compiler read it and use when deciding which portion to compile.
    >
    > The idea is indeed to have a set of hosts on which it compiles without
    > modifying the source code (clearly new hosts would need to be added)
    >
    > The usual way if it were an external library would be to set the path for
    > .h and .lib into the IDE or Makefile, however this is not the case.
    >
    > Giulio.


    Most (if not all) compilers and platforms already have builtin such
    #defines.

    Examples:
    #ifdef _WIN32
    // Windows, 32 or 64 bit
    #endif
    #ifdef _WIN64
    // Windows, only 64 bit
    #endif
    #if defined(_WIN32) && !defined(_WIN64)
    // Windows, only 32 bit
    #endif
    #ifdef _MSC_VER
    // MS Visual C++
    #if _MSC_VER >= 1600
    // MS Visual C++ 2010 or later
    #endif
    #endif

    Look at the documentation of each platform/compiler to find out more.

    More generally, you can define such constants by yourself when invoking the
    compiler. Usually with the option -D (Example: -DMYHOST -DMYCOMPILER).
    This is equivalent to the following source code:
    #define MYHOST
    #define MYCOMPILER

    Tobi
     
    Tobias Müller, Dec 26, 2012
    #1
    1. Advertising

  2. On 12/26/2012 10:12 AM, Giuliano Bertoletti wrote:
    >[..]
    > I was hoping there exist a standard way to solve a non standard issue.


    Alas...

    There can be no "standard way" to address a platform-specific issue.
    The solution is always platform-specific and as such cannot be made
    standard. Stop looking for what can't exist, and start looking in your
    compiler manual and how-to guides specific to your compiler. Also,
    consider asking in the newsgroup (if such exists) or another place (like
    a Web-based forum) where developers for your OS come to discuss
    OS-specific solutions. If Windows is your target, there will be a
    wealth of knowledge on MSDN (.microsoft.com), for instance.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 26, 2012
    #2
    1. Advertising

  3. Tobias Müller

    1 2 Guest

    On Dec 26, 10:48 am, Giuliano Bertoletti <> wrote:
    > The solution was simpler than I though and was very close to the one
    > suggested.
    >
    > It works using something like:
    >
    > /D MSWINOS64BIT=$(MSWINOS64BIT)
    >
    > on the compiler switch.
    >
    > Then I defined an
    >
    > #if MSWINOS64BIT == 1
    > ...
    > #else
    > ...
    > #endif
    >
    > in the code and set the external environment variable:
    >
    > MSWINOS64BIT=1
    >
    > on the proper host.
    >
    > Apparently the only thing I was missing was the $(envvar_name) paradigm
    > to refernce an externally defined variable. The one suggested did not
    > work for in "/D MACRONAME=MACROVALUE", MACROVALUE is constant.


    I don't see the point of that. How is setting an environment variable
    so different/easier than modifying an entry in the project's
    properties or modifying something in the code?

    If what you want is to allow the project to build differently on
    different computers without modifying the project, maybe VC++'s
    "custom build steps" will be useful to you.
     
    1 2, Dec 26, 2012
    #3
  4. Giuliano Bertoletti <> wrote:
    > Il 26/12/2012 15:38, Tobias Müller ha scritto:
    >>
    >>
    >> Most (if not all) compilers and platforms already have builtin such
    >> #defines.
    >>
    >> Examples:
    >> #ifdef _WIN32
    >> // Windows, 32 or 64 bit
    >> #endif
    >> #ifdef _WIN64
    >> ...

    >
    > This is not as easy. First the _WINXX macro defines the target platform
    > and not the host OS. For example in my case, I don't have _WIN64 defined
    > even on a 64 bit os for my target application is 32 bit.


    If your build depends on the host platform, that's most probably a bad
    thing. Of course, you have to rely on a compiler, standard library headers
    and system headers to be present. But i think you should reduce other
    dependencies to a minimum.

    >> Look at the documentation of each platform/compiler to find out more.

    >
    > I tried, but found nothing. Besides I do not even know exactly what to look for.
    >
    >
    >> More generally, you can define such constants by yourself when invoking the
    >> compiler. Usually with the option -D (Example: -DMYHOST -DMYCOMPILER).

    >
    > I know, but none of them depends on the external environment.
    >
    > The problem is that compilers/linkers assume only .h and .lib files may
    > be scattered all over the system and provide ways to find them
    > (essentially providing a way to tell the compiler/linker in which folders to look for).


    They are usually installed in a few, well defined places. You can even add
    custom directories:
    - for VS < 2010, in the Options
    - for VS >= 2010, in the Project settings

    I don't know if those are also working for #import instead of #include, but
    if yes, it's probably the easiest way.

    > But in my case I need to pickup and import a COM object whose location
    > depends on where Microsoft Office is installed. Which is neither a .h or
    > a library in a strict sense.


    Why not just add the TLB to your project instead of searching the host OS?

    > I was hoping there exist a standard way to solve a non standard issue.
    >
    > Giulio


    Tobi
     
    Tobias Müller, Dec 26, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris P
    Replies:
    0
    Views:
    441
    Chris P
    Oct 28, 2003
  2. avishay

    Conditional compilation in VHDL

    avishay, Aug 1, 2005, in forum: VHDL
    Replies:
    4
    Views:
    3,024
    Andy Peters
    Aug 1, 2005
  3. Praveen
    Replies:
    0
    Views:
    363
    Praveen
    Apr 12, 2005
  4. Praveen Ramesh
    Replies:
    2
    Views:
    2,176
    Steven Cheng[MSFT]
    Apr 13, 2005
  5. Alec S.
    Replies:
    10
    Views:
    10,168
    Alec S.
    Apr 16, 2005
Loading...

Share This Page