Re: [Boost-build] Copy file to output directory

Subject: Re: [Boost-build] Copy file to output directory
From: Ian Emmons (iemmons_at_[hidden])
Date: 2011-04-11 23:11:48

Volodya,

On Apr 10, 2011, at 3:30 AM, Vladimir Prus wrote:
> On Friday, April 08, 2011 23:28:39 sichent wrote:
>> Ian,
>> 
>> thanks I followed your recommendations and the file is being copied to
>> the output directory... so i am facing another question now:
>> 
>> how do you know inside your unit test from where to open the copied file?
>> 
>> i tried to pass the name of the file through additional arguments to the
>> [ run ... ] rule or just use hardcoded "file.txt" name but seems that
>> working directory of unit test is where Jamfile is located and NOT the
>> path where tests's binary is generated...
> 
> Hi,
> 
> you seem to be going a rather long-winded route. Can you just have this:
> 
> 	run test.cpp : : input-file.txt ;
> 
> Then, you test.cpp will know it's own directory (in argv[0]) and the directory
> where input-file.txt is.
> 
> - Volodya

I'm not sure what sich's use case is, but my own is like so:  I have an application that loads a configuration file at startup via the following algorithm:

(1) It first looks for an environment variable containing the file's absolute path.

(2) If the environment variable is not found, it must behave a bit differently on Windows and *nix:

   a. On Windows, it query's the OS for the absolute path of the binary, and looks for the configuration file's canonical name within that directory.  On Windows this is the most-often used approach for finding the configuration file.

   b. On *nix, it looks for the canonical configuration file name within the current working directory.  On these platforms, the environment variable is the most-often used approach.

So, you can see that passing the file to the unit test as a command line parameter is not useful here, since the point of the test is to be sure that the code to locate the file by other means is working properly.

I was able to test 2a by making the file a dependency of the unit-test target and providing a copy target to copy the file into the build directory where the binary lives.  Note that for this reason I must use the unit-test target rather than run, which is recommended, because the build directory for run is different, and so the copy target puts the file in the wrong place.

I tested 2b by using another dependency and copy target to copy the file into the same directory as the test Jamfile (which becomes the test's working directory).  Note that this would be easier if I could explicitly set the working directory of the run target.

Testing 1 is (as far as I can determine) impossible with BB alone, because BB cannot set the environment of the test executable.  I solved this case with scripting external to the bjam invocation.

In short:

* Sometimes this sort of file copying is indeed necessary.
* My own jam file would be simpler if the run target did not use a different build directory from every other target.
* run (and other unit testing targets) should take as additional parameters a directory to use as the working directory and a list of additional variables to add to the test's environment.

Thanks,

Ian