[tz] [PATCH] Support building zic.exe and zdump.exe natively on Windows with Visual Studio nmake.

[Manuela Friedrich]

Hello Paul,

I managed to write a minimal tools.ini file for Windows that doesn't require changes of the Makefile so that compiling on POSIX systems will work as before. It contains Windows versions of the version and version.h rules as these use shell commands in the base Makefile which will not work on Windows.  Also, tools.ini contains any windows specific flags to the compiler, variables, suffixes and windows specific compilation rules.

As explained earlier our customers will download the latest release from your ftp server and will need the tools.ini file and the getopt.c file as part of your latest release package. Can I send you a new patch with these files?

Stat on Windows is documented on msdn: https://msdn.microsoft.com/en-us/library/14h5k7ff(v=vs.100).aspx
Having /. appended to a filename is not mentioned, potentially it's not expected.  
In the debugger I see stat returning 0 for an existing file with /. appended but -1 for a non-existing file with /. appended.

Regards
Manuela Friedrich

-----Original Message-----
From: Paul Eggert [mailto:eggert at cs.ucla.edu] 
Sent: Mittwoch, 31. Januar 2018 20:55
To: Manuela Friedrich <Manuela.Friedrich at actian.com>; Time Zone Mailing List <tz at iana.org>
Subject: Re: [tz] [PATCH] Support building zic.exe and zdump.exe natively on Windows with Visual Studio nmake.

On 01/31/2018 08:17 AM, Manuela Friedrich wrote:
>
> We did more research on the topic and found a way that we can make 1 
> makefile work if we redefine a number of variables including some 
> scripts (shell/batch code) in tools.ini for Visual Studio compiler and 
> tools.gcc for gcc compiler and then reference these variables in 
> Makefile, each compiler type will load their own compiler specific 
> file with variables and all the variables will need to be 
> parameterized in 1 platform independent makefile.
>

That sounds like it might be a reasonable way to go, if it isn't too intrusive on the current Makefile. The goal would be for the Makefile to work unmodified on POSIX platforms, but you could use make FOO=x BAR=y etc. to get it to work with nmake on Microsoft platforms.

> Alternatively, we can keep the two separate makefiles, it’s pretty 
> common to have two separate makefiles
>

I'd rather avoid this, as it's more work to maintain two closely-related makefiles than to maintain one. Among other things, I couldn't easily test the nmake version.

> Regarding the Nameslashdot change on Windows stat() behaves 
> differently. It always returns 0 when run on a filename with /. appended.
>

Even if the file does not exist, or the file exists but is not a directory? That sounds weird. Is this behavior documented somewhere?


> Windows does not define S_ISDIR, but S_IFDIR and S_IFMT so I suggest 
> this change:
>
Thanks. I installed the attached patch into the development version; 
it's like your suggestion but moves the backward-compatibility hack more 
out of the way. As a bonus, this ports this part of tzcode back to 7th 
Edition Unix (1979).