[DGD] DGD For MSys, mark 2

[Shentino]

You probably know this by now but felix recently reworked the
makefiles to gnu standards and also autodetection of platform.

On Mon, Jan 7, 2013 at 8:09 PM, Jared Maddox <absinthdraco at gmail.com> wrote:
>> 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.
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd