[Simh] Makefile conditionals.

[Brett Bump]

On Tue, 2 Oct 2007, Peter Lund wrote:

> On Mon, 2007-10-01 at 12:02 -0600, Brett Bump wrote:
>
> > I guess that's why it's for hobby use, but we could probably get Bob to
> > add a few lines to the makefile (and the zip archive).  When I first saw
> > this problem, I just looked into the makefile and noticed that the build
> > information was only checking for Apples, PizzaBoxes and Winderz.
>
> And apparently it only works accidentally on OS X.  I know for sure that
> it only works by accident on cygwin (and you actually have to either
> disable one of the simulators or patch it to make it build).
<snip>
>
> That would have to be 'ifeq ($(shell echo $$OSTYPE),linux)' to have a
> better (but not perfect) chance of success.

Hey, if it works (and works for most platforms), great.  I've actually
seen the makefile improving quite a bit from the V2-V3 releases, but I
dare say "I" don't want to be the one to suggest Makefile changes if there
are people more competent with the conditional guesswork than myself.

<snip>
> Furthermore, the default POSIX shell (the one you get when you
> run /bin/sh) is dash, not bash.  Dash is also the default shell for
> users.  Dash is both very minimal and very POSIX compliant.  It does not
> have the OSSHELL variable at all.

That (again), depends on what your running:

bash-3.00$ whereis bash
bash: /bin/bash /usr/bin/bash
bash-3.00$ whereis sh
sh: /bin/sh
bash-3.00$ ls -al /bin/sh
lrwxrwxrwx  1 root root 4 2005-06-29 16:58 /bin/sh -> bash

Oops. ;-)

> There are other POSIX compatible shells (ksh/pdksh, for example).
>
> A better way is to use uname and grep -i for linux in the output.
> That actually works on more platforms.

That's probably true (good idea).  Should catch pretty much all of the
different strains of *nix, BSD and Open Source BSD/linux distributions.

<snip>
> >
> > I put this 18 lines down in the makefile.  This should be accurate for
> > "most" of the linux distributions, PROVIDED that you MAKE SURE you build
> > from csh.  Don't use the default BASH (and many linux sh are BASH) as
> > the environment variables are different.
>
> Precisely.  [And who on Earth uses csh these days? ;)]

Use?  No.  Make SimH?  Sure. ;-)  But even csh is usually tcsh on many
systems (just like sh is bash, or Dash on Ubuntu).  The point beccomes
moot if you use uname instead of environment variables anyway.
(But Bill Joy might never forgive you for your comment ;-)

> My 'build' branch at http://vax64.dyndns.org/repo/hg has these tests.
>
> There are many other problems with the current makefile.  The 'build'
> branch is an attempt to fix them.  It is a little bit out of date as it
> doesn't build all the simulators but the code in my local directory
> does.
>
> > It would also be nice if Bob would create an empty BIN folder in the zip
> > archive (since the build stops when it's not there the first time).
>
> Yes!
>
> An other improvement would be to include the directory in the zipfile,
> preferably with the version number encoded in it:
>
> simh-3.7-3/scp.c
> simh-3.7-3/scp.h
> simh-3.7-3/Interdata
>  ...

YES!!

And while we're just making constructive "brain-storming" here, how about
(even just short and simple) README, INSTALL, COPYING (gnu?), a COPYRIGHT
or LICENSE (Bob would have to write this) files and a changelog file?  I
don't want to get all *nix-ish here, but that IS something I have come to
depend on when installing most other packages.  I really have no issues
with the pdf manuals (discussed a while back), but a few of these simple
files (which could refer back to a larger manual) could be benificial.

> (simh-3.7.3/ with a correspondingly named simh-3.7.3.zip would of course
> be better.)

The hyphens don't bother me near as much as a wanting a simh-3.7-3.tgz or
simh-3.7-3.bz2 does.

> Just a bit of poka-yoke.
>
> >   The
> > missing BIN folder is just a trivial point, but catches me every time I
> > open up an updated release (make...wait, BIN error, mkdir BIN, make).
>
> Actually, it can be fixed in the makefile, too, which is what I've done
> in the 'build' branch.  Since I build each simulator in its own
> directory, I needed to create directories on the fly anyway.
>
> -Peter
>

As long as this doesn't conflict with the ability to still make "option" I
don't see any problem with that.  Most of us are probably only making for
one emulator anyway.

Brett