[CMake] Coverage tests with gcov under Linux

[John Doe]

Since this is the fault of cmake, you should perhaps have it set the
proper locale when the program first begins.  I have never done this,
but a google search reveals stuff like:

  std::setlocale(LC_ALL, "En_US");
  std::fscanf(priceFile,"%lf",&price);
  // convert $ to DM according to the current exchange rate
  std::setlocale(LC_ALL,"De_DE");
  std::strfmon(buf,SZ,"%n",price);
  std::fprintf(invoiceFile,"%s",buf);

for C

or for C++
priceFile.imbue(std::locale("En_US"));
invoiceFile.imbue(std::locale("De_DE"));
moneytype price;
while ( ... )  // processing the German invoice
{
  priceFile >> price;
  // convert $ to DM according to the current exchange rate
  invoiceFile << price;
}

See http://stdcxx.apache.org/doc/stdlibug/24-3.html for an example.

Regards,

Juan

On Fri, May 9, 2008 at 5:23 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2008-05-09 16:56-0500 John Doe wrote:
>
>> in tcsh:
>>
>> setenv LC_ALL POSIX
>>
>> or if you need utf-8
>>
>> setenv LC_ALL en_US.UTF-8
>>
>> In bash:
>> export LC_ALL=en_US.UTF-8
>
> That should be a good workaround, but ideally cmake should avoid locale
> issues like this one if at all possible since internationalization is
> becoming more and more ubiquitous on all platforms.
>
> So, Bill, is there some good alternative to parsing for the locale-dependent
> "Lines executed" string or are you stuck with it?
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>