[Simh] A new version...

[Howard M. Harte]

One thing to try us using the bash shell under Windows, and then use  
that to run gmake.  I've seen some cygwin tools like gzip fail in a  
Windows command prompt, but work fine if executed from within bash.

-Howard


On Sep 20, 2008, at 1:09 PM, Toby Thain <toby at telegraphics.com.au>  
wrote:

>
> On 20-Sep-08, at 3:42 PM, Terry Newton wrote:
>
>> --- On Sat, 9/20/08, Philipp Hachtmann <hachti at hachti.de> wrote:
>>> downtime? The latest version is
>>> http://hachti.de/simh/readline-hack-08092001.zip
>>
>> Found it after my post.
>>
>> If v3.81 make for Windows is used I get the following
>> error message...
>>
>> Command>build_mingw
>>
>> ! was unexpected at this time.
>>
>> mingw32-make: *** [NOVA/nova_sys.o] Error 255
>>
>>
>> This occurs with both the first /sihm/Makefile you posted
>> and also with the makefile from ..08092001.zip (slightly
>> edited to take out the readline support, not testing that
>> yet), and exactly the same error occurs whether run in
>> a real install of XP Home using mingw-make.exe or running
>> in my virtual install with a totally different build
>> of v3.81 make.exe (not from the mingw project).
>>
>> So basically v3.80 make gives a "virtual memory exausted"
>> error, and v3.81 gives a "! was unexpected" error,
>> regardless of whether I'm running virtually or not and
>> regardless of which build of make is used. At least
>> based on a limited sample size I've tried, but I think
>> I see a pattern... complex stuff breaks under Windows.
>
> What's complex about it? This seems all very straightforward...
>
>>
>> Of course it could simply be a bug...
>>
>>> It is available. And will stay available. I'm open for
>>> suggestions, too.
>>
>> Cool. One option is to simply don't try to make it work
>> under Windows, that operating system is targeted towards
>> more normal uses, and is often not approprate for complex
>> development tasks unless certain precautions are taken,
>> such as using simple makefiles.
>
> This is just superstition. When running Cygwin or MinGW, it's an
> emulation environment that should really be able to do what you're
> asking it to do (memory notwithstanding). GNU make on MinGW is
> *exactly* the same program. If there's a bug here, we can do more to
> locate it, instead of giving up and saying 'this is never going to
> work under Windows'.
>
> I am happy to help find the problem here, since I can hold my nose
> and boot WinXP, and/or set up VirtualBox.
>
>> There are inherent limits
>> on string sizes etc in Windows that don't apply to Linux.
>
>
> Why do you think such things, if true, are affecting THIS Makefile?
> More investigation of the problem is required.
>
>> ...
>>
>>> My problem is that I don't have those exotic systems
>>> SIMH could be built
>>> on. I have only my Linux - and small minicomputers like
>>> PDP8 etc.
>>
>> So long as it's not made the default for everyone, ...
>
> Why not? Every other project under the sun is expected to build with
> a GNU Makefile. It will work on all major systems and *should work*
> under Cygwin and MinGW as well. I do not yet accept your hypothesis
> that it can't work there.
>
> The old Makefile will be retained anyway.
>
> Unlike Philipp's, which is intended to work everywhere GNU make is
> available, the 'old' Makefile is not claimed to work -anywhere- in
> particular,  but 'happens' to work for you. For example, it's not
> claimed to be written for any particular subset of make features. And
> as somebody who is experienced in writing Makefiles, I can say that
> it is harder to write a portable makefile for a 'lowest common
> denominator'. The result will be more verbose and more fragile. You
> might get it working for, e.g. BSD or Solaris make, but then what
> about NMAKE? etc, etc.
>
> To make such an attempt, the targets should be defined; for example,
> "must work with the bundled non-GNU make on FreeBSD, Solaris,
> HPUX, ..." (it's now pretty hard to find a current system with a non-
> GNU make).
>
> It's not enough to say 'the new Makefile needs to work everywhere
> that the old one did'. That's not specific enough, because it's not
> testable. And, as I've said before, GNU make is a very useful de
> facto standard; not just in terms of its ubiquity (including
> embedded) but also because of its reliability, maturity and pragmatic
> extensions, which simplify the task.
>
> --Toby
>
>>
>> Terry
>>
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>