[CMake] Copying Files into build-dir under Visual Studio vs.Codeblocks/Win32 vs. Codeblocks/Linux

Fri Feb 10 14:14:50 EST 2012

That's a nice method too.  I suppose the hard coding wouldn't matter in a UnitTest.

Aaron Meadows

-----Original Message-----
From: cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] On Behalf Of Michael Jackson
Sent: Friday, February 10, 2012 10:37 AM
To: CMake ML
Subject: Re: [CMake] Copying Files into build-dir under Visual Studio vs.Codeblocks/Win32 vs. Codeblocks/Linux

Specifically on point "b" below. I configure a header file with the location of each input file. That header file is then used in the unit tests as the path to the file. That way it works for anyone in any directory on any operating system.

// Example Input header file
namespace Test1
{
   const std::string TestFile("@DATA_DIR@/MyInputFile.dat");
}

Then in my CMakeLists.txt file I have a CMake variable (DATA_DIR) that the user can set. After the variable is set then I use "configure_file(...)" to configure the header. Then in the actual test if I need to use that file:

void MyTest()
{
    FILE* f = fopen(Test1::TestFile.c_str(), "r"); ....
}

This setup avoids any copying of the files (at least the data files) into various directories.

Hope that helps
Mike Jackson

On Feb 10, 2012, at 9:22 AM, aaron.meadows at thomsonreuters.com wrote:

> (Wow, Eric, I didn't know about CMAKE_CFG_INTDIR!  Seems like you are 
> teaching me all kinds of things this week...)
> 
> 
> It sounds like what you are missing is having the command executed by Visual Studio, so it can do the substitution of the $(Configuration) variable, which is why you need to use the add_custom_command() function.
> 
> 
> 
> As a side note, I've had to deal with this problem before and have handled it in a couple of different ways, depending on what I was trying to accomplish:
> 
>  1) Finding DLLs -- for UnitTests that are run automatically, I write scripts ahead of time into directories for each configuration type which append the paths where various 3rd Party DLLs are stored, then execute those scripts as part of a post build event to run the UnitTest.
> 
>  2) Test Data -- I use one of two methods:
> 
>    a) Copy all the data into each of the configuration directories ahead of time (by iteration over CMAKE_CONFIGURATION_TYPES).  This saves needing to copy the identical file from a source data directory to a binary directory over and over each time I build.
> 
>    b) I change the executable so I can pass it a data directory to read from.  This saves making many copies of identical data for each different configuration type.
> 
> Hope that helps!
> 
> 
> Aaron Meadows
> 
> 
> -----Original Message-----
> From: cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] On 
> Behalf Of Eric Noulard
> Sent: Friday, February 10, 2012 2:42 AM
> To: Stefan Fendt
> Cc: cmake at cmake.org
> Subject: Re: [CMake] Copying Files into build-dir under Visual Studio 
> vs. Codeblocks/Win32 vs. Codeblocks/Linux
> 
> 2012/2/10 Stefan Fendt <stefan at sfendt.de>:
>> Hi,
>> 
>> I'm (still) quite unsure if this isn't an FAQ (or if not maybe should 
>> be one), but I have read through everything I could google-up 
>> regarding this topic and found nothing usable...
>> 
>> I'm writing an x-platform-project which will be compiled using 
>> different compilers and or under different systems... for this 
>> project I am required to move some files from some location 
>> (source/data) into the build-directory. Whileas this works under 
>> Linux/Codeblocks/GCC as well as Windows/Codeblocks/MinGW it doesn't 
>> for Visual Studio... Under Visual Studio the files always are copied 
>> to some directory-location directly above the actual binary-directory.
>> 
>> I've tried using ${CMAKE_CURRENT_BINARY} and it copies the files to 
>> the marked position:
>> 
>> build/                        <--- copies  into this directory 
>> build/Debug build/Release build/source
>> 
>> After that I tried to do it with GET_TARGET_PROPERTY(... PROPERTY 
>> LOCATION). I then get something like this...
>> 
>> 'build/$(Configuration)'
>> 
>> ...which of course doesn't solve the problem, too... because the 
>> configuration under Visual Studio is only known after 
>> CMake-Generation of the solution and running the compiler...
>> 
>> So, what is the suggested method of (if you can't avoid it) copying 
>> files from anywhere into the build-directory, which is as compiler 
>> agnostic as possible..?
> 
> You may use CMAKE_CFG_INTDIR.
> 
> Try:
> cmake --help-variable CMAKE_CFG_INTDIR
> 
> You'll get some example with custom command/target.
> 
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » - 
> http://www.april.org
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
> 
> This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.