none
Set Output File in code

    Question

  • Is there a way to set the outputfile that the compiler is generating programmatically?

    I'm working on a Visual Studio 2005 C++ project that generates an executable used for dozens of products.  There are dozens of configurations we use to set branding and other configurations based on which specific product the .  In other words, the URL used for authentication, the directory that applications are installed, the URL accessed to download updates, etc.  All of our products use the same source, with various #defines set based on the Project Configuration being built at the time, which we have flagged in VS2005 under Preprocessor Definitions: _$(ConfigurationName):

    file: branding.h
    #ifdef _CONFIG1
      #define K_LOGIN_URL TEXT("http://www.foo.com/bar")
      #define K_IMAGE_FILE TEXT("config1.jpg")
    #endif
    #ifdef _CONFIG2
      #define K_LOGIN_URL TEXT("http://www.foo.com/baz")
      #define K_IMAGE_FILE TEXT("config2.jpg")
    #endif

    Everything so far has worked great, but modifying the linker's OutputFile programatically has proven to be a task.  We'd like to add something like the following:

    #ifdef _CONFIG1
      #define K_OUTPUT_FILE TEXT("myApp_Gold_Edition.exe")
    #endif
    #ifdef _CONFIG2
      #define K_OUTPUT_FILE TEXT("myApp_Platinum_Edition.exe")
    #endif


    Is there any way to do something along these lines?  I searched the #pragma directives and haven't found any way to set a $(Variable), nor have I found a way to directly #override OutputFile.

    Thank you for your time

    ~Shane Ebersole
    Tuesday, April 17, 2007 2:35 PM

Answers

  • In that case I would recommend something like option 1.  When you think about it, what you want to do isn't so much part of the compile/link process as it is part of the "packaging" process.  In this case, I would suggest making all configurations call a common post-build script.  This post-build script in turn reads an environment variable or some other file to copy the output exe to the right file name. 

    Now, this script as well as whatever file/files it reads should be put under version control, which meets your requirements.
    Tuesday, April 17, 2007 6:47 PM

All replies

  • Instead of doing it declaratively in code, could you do it:

    1) With a custom build task or post-build batch that renames the (well known) output file to the right name by reading some variable or file?

    2) By adding another project configuration in Visual Studio?  For example, you normally just have Debug/Release but what if you had "myApp_Gold Release/my App_Gold Debug, MyApp_Platinum Release/....)"  that way you could configure these things on a per configuration basis
    Tuesday, April 17, 2007 4:40 PM
  • We have what you described in section 2, which is a fine workaround for now, but it's not in the code, which means it isn't Version Controlled very well.  When non-programmers need to make a change to our branding, they can easily modify the .h file, not so much the VS2005 project settings (they don't even have Visual Studio 2005 on their systems).

    It also makes creating new configurations even more of a hassle than it already is.  We have been able to just copy the old configuration and give it a new name, then use marketing's branding header file with a new #ifdef section.

    I keep thinking that there has to be a way to declare this in the code...it seems like a feature a lot of people would use, yet Google and MSDN has failed me ("outputfile" is pretty broad).  I can't even find other people asking the same question as me.
    Tuesday, April 17, 2007 5:07 PM
  • In that case I would recommend something like option 1.  When you think about it, what you want to do isn't so much part of the compile/link process as it is part of the "packaging" process.  In this case, I would suggest making all configurations call a common post-build script.  This post-build script in turn reads an environment variable or some other file to copy the output exe to the right file name. 

    Now, this script as well as whatever file/files it reads should be put under version control, which meets your requirements.
    Tuesday, April 17, 2007 6:47 PM
  • One final question, although it probably sounds silly.

    Does the Visual Studio's /OUT flag do anything besides describe the file name (ie, any metadata in the binary)?  I wouldn't expect there to be any issues with having a script that merely renames the files, but just would like to be safe before spending even more time following a solution that will ultimately not be what we're looking for.
    Tuesday, April 17, 2007 7:27 PM