[DGD] DGD For MSys, mark 2

[Jared Maddox]

> Date: Sun, 06 Jan 2013 14:09:14 +0100
> From: "Felix A. Croes" <felix at dworkin.nl>
> To: dgd at dworkin.nl
> Subject: Re: [DGD] DGD For MSys, mark 2
> Message-ID: <E1TrpyU-0002qP-CF at pattern>
>
> Jared Maddox <absinthdraco at gmail.com> wrote:

> Your Makefiles compile with -DMSys -D_WIN32_WINNT=0x501.  To get DGD to
> compile, you have to define WIN32, which your patches don't do.  If you
> can compile DGD with your patches, there must either be other changes
> that were not included with your patches, or MSYS has WIN32 as a
> predefined macro.  Platforms are not supposed to predefine macros
> without a leading underscore, and Visual Studio does not predefine it,
> but who knows what MSYS does. :)
>

MSys defines it inside the windef.h file. It defines the version with
a leading underscore in the same place. Could you check to see if
Visual Studio does the same?

It does look like I should be defining WINVER (along with WINNT)
instead, though. If you set RC_INVOKED and WIN32_LEAN_AND_MEAN then
e.g. winuser.h gets included before windef.h, which is probably why I
set _WIN32_WINNT instead of WINVER (unless there's something that's
included by windef.h or stdarf.h that I just didn't notice).

>> There might be a larger set of variables that it would be wise to set,
>> but that one seems to get the compilation done.
>>
>> Note that I'm not actually certain about specifically setting the host
>> to MSys. MSys itself is distinguished with a variable called MSYSTEM,
>> the value of which indicates whether you're compiling ON MSys, or ON
>> MSys FOR MSys (these aren't actually the same, since MSys apparently
>> adds something to better simulate a *nix environment). I ignored the
>> value itself, since DGD already has code to compile for Windows.
>
> GNU Make has the annoying feature that any environment (shell) variable
> is copied as a Makefile variable.  So if someone, somewhere, has an
> environment variable MSYSTEM set on a non-MSYS host, your Makefile
> will break.  That is why I ignored pre-set variables and used my own
> OS detection code.
>

I have a number of ways that I'd like to see make work differently
myself (though unfortunately, by the time I got done it wouldn't be
compatible with makefiles anymore).

As for the OS detection code, it was specifically returning the
specific version of Windows that I run (XP). Suffice to say, that's a
bit more platform-specific than I was looking at. At the same time, I
wanted to print an informative error message if someone tried to use a
mingw/msys make from the Windows command line, since uname is almost
universally not available on Windows.

I settled on MSYSTEM because that seemed the "safest" option, though I
suppose that I should at the very minimum do that string comparison on
it.

>> Am I using HOST correctly?
>
> HOST is supposed to be set to a symbol that selects the platform in
> dgd/src/host.h.
>

So it does need to be WIN32 for my port. I guess I'll be giving Make
another argument for host/makefile.

>> What's your opinion on makeheader.win? I wanted to make that code
>> somewhat modular, so that it could be adapted to e.g. Haiku, if anyone
>> wanted to do that in the future. Also, I thought that it was impairing
>> readability by being in the main makefile.
>
> It's messy.

Amen. That's a pretty big reason why I put it into a separate file, in
fact. I'll see what I come up with after testing the value of MSYSTEM.

> I think your patches are still far from ready for merging
> into the master branch, but I've created an msys branch for them in the
> DGD repository.
>

Guess it's time to install TortoiseGit.

>> I'm worried that this patch series will prevent compilation on Cygwin.
>> Can you test this? I don't have Cygwin installed on my machine, and
>> would prefer to not dabble in it.
>
> All I have installed is Visual Studio 2010 Express, on which DGD compiles
> without a hitch.
>

Then I'll just add a bit to the error message saying something like "I
you're on a *nix-sh system and this won't compile, please contact the
mailing list".

>> Should the "HOST_OVERRIDE" switch be enough for any other *nix-ish
>> platforms on Windows?
>
> Due to the automatic import of environment variables into GNU Make,
> depending on a predefined symbol is a bad idea.
>

I'm challenged to think of another way to do it, though (thinking
about it, I should at least name it DGD_TARGETHOST). Do you know of
any better methods?

>> Also, any idea why comp/parser.h / comp/parser.c, host/dosfile.c /
>> host/dosfile.o, and host/windgd.c / host/windgd.o don't get deleted on
>> "make clean"? Did I accidentally break something?
>
> The files parser.c and parser.h are not removed so "make clean" will not
> disable compilation on a system without yacc installed.  Why the others
> are not removed, I don't know.
>

I'll just ignore them, then.

>> Anything else that I should work on for this patch series (I recall
>> some of the pre-compiler stuff causing problems, but I don't want to
>> deal with that yet)?
>
> Take a look at the msys branch of the DGD repository.  It is probably
> easier, for both of us, if you start to work with a proper git
> repository rather than by posting patches to the mailing list.
>

Yeah, I figured that I would do that pretty soon anyways. A big part
of why I was posting here was just to get working (even if dubious)
patches where I could be certain that a web search would find them.
That way, if anyone else came along later wanting to do it, they would
at least have a starting point.

I'll probably work on my next revision tomorrow, or the day after.

>> Incidentally, it looks like the web browsing for the mailing list is
>> down (Secure Connection Failed error on Firefox). Is there somewhere
>> to check for it other than your site?
>
> The mailing list archive is not down.  The host certificate was replaced,
> which is probably why Firefox gives that message.  Remove the old
> certificate for www.dworkin.nl from Firefox, import the new one, and
> you'll be all set.
>

Nope, same problem. On Firefox 17.0.1:

Secure Connection Failed
An error occurred during a connection to mail.dworkin.nl.
Peer reports incompatible or unsupported protocol version.
(Error code: ssl_error_protocol_version_alert)
- The page you are trying to view cannot be shown because the
authenticity of the received data could not be verified.

Not really certain what the problem is, but fortunately I don't really
use the web interface anyways, I only noticed because I was trying to
figure out if the email with the attachment had gotten through or not.