test1148: disable if decimal separator is not a point

[MarcelRaad]

LC_NUMERIC doesn't work on Windows, so just replace the decimal comma
with a decimal point in the expected result.

[dfandrich]

There are a bunch of tests that set the environment in this way and they all can't be fixed this way. And are you sure that , and . are the only two decimal separator characters possible in any locale? It seems a better way to solve this would be to detect environments where the environment can't be set like this and skip the test, or skip the test if the environment requested is different from the one actually currently set.

[MarcelRaad]

There are other decimal separators, but I couldn't find any others that are for Hindu-Arabic numerals. Good point, I have to test what happens with languages with other numeral systems. Removing <setenv> is probably bad then.

How would you implement skipping such tests? Using <precheck>?

[MarcelRaad]

I tried with locales ps_AF.UTF-8 and prs_AF.UTF-8 and they both failed with removing setenv while succeeding before, so this cannot go in as-is.

This happens when building for native Windows (e.g. using MSVC or MinGW), but not when building for MSYS, so there's probably no good solution without running any code.

[dfandrich]

A precheck would work. It would mean duplicating some of the information in the <setenv> section, though, but it affects a small enough set of tests that it's probably not worth building into the test harness.

[MarcelRaad]

That was fun! Something like this?

Unfortunately, Perl is not my native language and this is the first time I touched an automake file, so I'm not sure if I got this right. But it does work - the test is skipped in my German MSYS2 MinGW shell, where it previously failed, but not in my German MSYS2 MSYS shell, where it succeeds.

But, when I had chkdecimalpoint_SOURCES = chkdecimalpoint.c ../../lib/mprintf.c like many other test programs, I got errors about redefining the functions in mprintf.c without __declspec(dllexport) or something like this. I haven't managed to find out what I'm doing differently yet.
Also, I'm not entirely sure about the location of the helper program - chkhostname is located in libtest and used by non-lib curl tests, so I put it there too.

I still have to update potential other tests setting LC_NUMERIC as soon as this is OK.

[gvanem]

I got errors about redefining the functions in mprintf.c without __declspec(dllexport) or something
like this.

Try adding -DBUILDING_LIBCURL while compiling chkdecimalpoint.c.

[dfandrich]

I would expect a <precheck> like this would work without the need for an external C program: perl -e 'use locale; die("Test requires locale support") if not sprintf("%f", 1.234) =~ /\./'

[MarcelRaad]

Thanks to both of you!

I wasn't sure if there was a difference between perl and C. But if perl-only works, that's better. I'll make sure it generates the same result and update the PR accordingly.

[MarcelRaad]

Unfortunately, that doesn't work because MSYS2's perl always respects LC_NUMERIC, probably because it's an MSYS program - there's only one perl in /usr/bin for both environments.

[MarcelRaad]

Fixed the MSVC static CMake build, breaking the autotools build. Fixed that, breaking the Linux CMake build 😃
I still don't understand what parts of Makefile.inc are used for CMake, the CPPFLAGS are not...

[MarcelRaad]

Finally all configurations are passing. I haven't found any other curl test setting LC_NUMERIC.