Back to General and Gameplay Programming

Custom environment macro

General and Gameplay Programming Programming

Started by Khatharr July 22, 2015 06:48 PM

5 comments, last by Khatharr 8 years, 9 months ago

Khatharr

8,814

Author

July 22, 2015 06:48 PM

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).

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

3pic_F4il_FTW

816

July 22, 2015 07:14 PM

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.

Khatharr

8,814

Author

July 22, 2015 07:22 PM

I think there's _DEBUG for that. It's really not what I'm looking for. Thanks, though.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Lactose

11,696

July 22, 2015 07:46 PM

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.

Hello to all my stalkers.

jpetrie

13,220

July 22, 2015 08:16 PM

...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).

frob

46,221

July 22, 2015 09:15 PM

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.

Khatharr

8,814

Author

July 22, 2015 11:10 PM

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.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Custom environment macro

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Custom environment macro

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines