Thanx.  Applied with minor tweaks.

NEW_STRINGS are the new thing.  I don't care about  the !NEW_STRINGS path any more.   I've been removing the #else path on any file I have to touch where it's obvious and mechanical.  Basically, they're a TODO as sometimes, now that I don't care about old strings any more, there is a better/cleaner way to implement things.
On Tue Jan 07 2014 at 3:23:21 PM, Gerhard Olsson <gerhard.nospam@gmail.com> wrote:

GPSBabel.pro correction, should be for all platforms
* shapelib references were incorrect
* Setting NEW_STRINGS by default, as it was changed in r4679. At least msvs does not compile anymore without NEW_STRINGS.
* Adding include directories for msvs

Some various compile issues in shpopen.c and csv_util.cc
Suggest moving the README.msvc and removing msvs.
(I have a private patch for xmlstreamwriter.cc as described before.)

The last two files has been submitted before. Just being mentioned on the list could be sufficient for msvc.

/Gerhard



On Sun, Nov 10, 2013 at 12:11 AM, Gerhard Olsson <gerhard.nospam@gmail.com> wrote:
More MS Visual Studio:

* #ifdef for #include in xmlstreamwriter. MS uses include from the directory where the compiled file is located, not where compile is started from. (this for once a syntax I prefer)
http://msdn.microsoft.com/en-us/library/vstudio/36k2cdd4.aspx

* Some weird #ifdef limitation (related to NEW_STRING) in csv_util.
No dramatic change

* Slightly updated README.msvc file. I suggest the file is put in the gpsbabel directory and that the msvc directory is removed. (As that project file is not maintained)

* Problems with testo gpx with standard input is due to the test syntax. Normal stdin works fine.
 
And to comparing dates: strftime behaves differently in MSVS and other (I compare with Cygwin, where tests mostly passes).
Where Cygwin gives Thu Jan  1 00:00:00 1970, MSVS gives  01/01/70 00:00:00.
It does not matter that default locale is "C" and that locale is normally written "en-US" (instead of en_US) using setlocale() when the result will not match anyway.
Of course, GPSBABEL_FREEZE_TIME can be used (with _MSC_VER) to handle this, but this affects a lot of code (degrading other code).
I currently suggests that MSVS is kept as "development" only, not for production/tests. It is probably me that primarily uses MSVS anyway (a patched version with garmin.c lap_read_as_track() active as my GF305 has some HW problem).
Obviously, no further investigation if rounding handling can be improved.

/Gerhard



On Fri, Oct 4, 2013 at 12:51 AM, Gerhard Olsson <gerhard.nospam@gmail.com> wrote:

>> below

On Wed, Oct 2, 2013 at 10:50 PM, Robert Lipe <robertlipe@gmail.com> wrote:
 
Rounding is just a mess.  I don't have a great solution to that. Chasing sub centimeter location differences across OSes is pretty silly.  Maybe we need a better way to test this stuff.  Ideas welcome.
>> The reasonable for non binary is to round output. For binary formats there is no solution except keeping separate result files... Phew....

You can't imagine how badly I don't want to do that.
>> I believe I can, but that is probably not

Maybe we just say that Cygwin is the only reasonable way to get results that match with testo on Windows.   After all, you need Cygwin to run the shell script anyway, right?
>> For sure, I test with the Cygwin build. I just wanted to give the status for MSVS, what works and what dont.

I know this is what results in that alien look I get when I ask the contributor of a new format (that has ^M's at the end of all the lines) for a test case we can slam into testo, but in nearly every case, given a sample file we can round trip it through GPX and get coverage that's usually "good enough".
 
Didn't we force testo to run in US.UTF-8 pretty much for you in r4525?  Did this not help?
>> Helps for Cygwin, not honored in native Win apps.  I have not looked for a substitute.

Is there a 'setlocale' in Win32?  Maybe we do 
if getenv("GPSBABEL_FREEZE_TIME) setlocale(...
That's kind of an unfortunate way to communicate this to the executable, but that's the hammer we have.
>> Something like that, yes. I plan to look at it