Jump to content
  • Advertisement
Sign in to follow this  
Khatharr

Custom environment macro

This topic is 1246 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Heyo.

 

I'm using VS2013 and I have a lib that I use to do memory leak checking while debugging that's a little nicer than the crt one. All I have to do to use it is #include it, but I also have to remember to remove the inclusion when I'm done and want to send the code off to someone else. So I figured I should make the inclusion conditional with something like

 

#ifdef KHATBOX

#include <vld.h>

#endif

 

...but I can't figure out how to define KHATBOX in such a way that it's not going to go along with the project.

 

Preferably I could set this up once and then have it just be a normal part of my env.

 

Anyone know if this is possible and how to go about it? I found some stuff about defining environment macros in VS, but that appears to be referring to the path abbreviation crap like $(SolutionDir).

Share this post


Link to post
Share on other sites
Advertisement
You could just define it in the compiler options of the debug build using /D

That way it would automatically be excluded when building a release build.

Share this post


Link to post
Share on other sites

You can create a new solution configuration, and add the define to the preprocessor for that configuration:

1. From the Solution Configurations drop-down (by default containing Release, Debug and Configuration Manager...), select Configuration Manager....

2. In the Active Solution Configuration drop-down, select <New...>.

3. Name your solution configuration something appropriate, e.g. MemLeak Debug or MemLeak Release.

4. Copy settings from an existing solution configuration if appropriate.

5. Close the Configuration Manager.

6. Go to Properties on your project (e.g. right click your project in the Solution Explorer and select Properties).

7. Ensure your new solution configuration is selected as the configuration to be edited.

8. Go to Configuration properties --> C/C++ --> Preprocessor.

9. Under Preprocessor Definitions, add the wanted preprocessor definition -- in your case KHATBOX.

10. Select OK, and you should be good to go.

 

#ifdef KHATBOX will now be true for your newly created solution configuration, and false for the other ones.

Share this post


Link to post
Share on other sites

...but I can't figure out how to define KHATBOX in such a way that it's not going to go along with the project.

 

 

 
You want to /DKHATBOX only if you're building it, and not have that set anywhere in the project options?
 
 
To do so you can use the little-known CL environment variables. Set (however you prefer) the _CL_ environment variable to /DKHATBOX, for example, and it will be appended to the cl.exe arguments for every file compiled.
 
As these are environment variables, be sure to set them in the appropriate context for your use (that is, don't just set them in a cmd.exe window if you want them to persist beyond that window and processes launched from that window, et cetera).
Edited by Josh Petrie

Share this post


Link to post
Share on other sites

If you're looking for ways to not have the files visible in your project at all, that's possible too.

 

 

Start by building the libraries separately outside of the project. Make sure all the necessary build settings are identical, such as runtime settings, alignment, defines, and so on.  Make sure you do not check in your external library, which is most easily done by keeping it in a completely different path.

 

Then use environment options -- which are not checked in -- to support the alternative include paths, library paths, and defined values. That will pull your alternate header files, link to your alternate libraries, and define your alternate #define definitions. 

 

 

Keeping semi-secret values in environment variables is very valuable in development generally, especially in server development. There are many values that work well with environment variables. Custom paths can be easily modified, although these may be a better candidate for config files. Credentials and passwords should never be put in code, and also never put in configuration files due to the risk of being accidentally submitted or overwritten.  It is often best to use environment variables that have no risk of being submitted to version control, and are unlikely to ever be modified accidentally.  

 

Similarly with compilation, you can build semi-secret additions by setting command line options through environment variables that are special for that computer.

Share this post


Link to post
Share on other sites

You want to /DKHATBOX only if you're building it, and not have that set anywhere in the project options?


Yeah, so I can include vld within an ifdef block and not have to worry about remembering to comment it out or switch to crtdebug when I send the project to someone else.

Set (however you prefer) the _CL_ environment variable to /DKHATBOX

 
That seems to have done it. The code section is dimmed in the editor, but when I compile and run it's including the indicated section.
 
Thanks, all.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!