clean up makefiles

[masinter]

#if !defined(LINUX) && !defined(MACOSX) && !defined(FREEBSD)
/* these are in the POSIX standard /
#define getwd(x) getcwd((x), MAXPATHLEN)
#define getrusage(x, y)
#define getpagesize() 4096
#endif / LINUX , MACOSX, FREEBSD */

should have && !defined(OS5) added to the other !defined entries -- i believe that Solaris 10 has the POSIX standard functions and doesn't need them defined as they are here.

The hardcoding of what is and isn't (or more accurately, was and wasn't) available in the libraries was not particularly well handled at the beginning and then people went and added all kinds of special cases when things didn't compile on new versions of the OS. Sigh. This is one of the things that needs to be cleaned up (and I don't think that GNU Autotools is much better!!)

[nbriggs]

I've already fixed that by taking out the -DSYSVONLY for OS5 -- it looks like this: #ifdef SYSVONLY #if defined(INDIGO) || defined(OS5) || defined(MACOSX) || defined(FREEBSD) || defined(LINUX) #else #define seteuid(x) setresuid(-1, (x), -1) #endif /* INDIGO, OS5, MACOSX, FREEBSD, LINUX do have seteuid */ #if !defined(LINUX) && !defined(MACOSX) && !defined(FREEBSD) /* these are in the POSIX standard */ #define getwd(x) getcwd((x), MAXPATHLEN) #define getrusage(x, y) #define getpagesize() 4096 #endif /* LINUX , MACOSX, FREEBSD */ #endif /* SYSVONLY */ $ grep SYSVONLY makefile-* makefile-ISC.i386-x:DFLAGS = -DFSERROR -DAIX -DSYSVONLY -DSYSVSIGNALS -DNOASM -DLOGINT -DNOPIXRECT $(XFLAGS) -DBYTESWAP -DAIXPS2 -DFLTINT -D_I386 -DNOETHER -DFORKCOMM makefile-hpux.hp9000-x: -DSYSVONLY \ makefile-init.sgi: -D_IEEE -DINDIGO -DSYSVONLY -DNOETHER -DNOPIXRECT -DSYSVSIGNALS -DNOFORN \ makefile-init.sparc: -I$(OPENWINHOME)/include -DSYSVSIGNALS -DSYSVONLY \ makefile-irix.sgi-x: -D_IEEE -DINDIGO -DSYSVONLY -DNOETHER -DNOPIXRECT -DSYSVSIGNALS -DNOFORN \ makefile-riscos.mips-x: -DSYSVSIGNALS -DSYSVONLY \ makefile-sunos5.i386-x: -I$(OPENWINHOME)/include -DSYSVSIGNALS -DSYSVONLY \ So other than fixing the makefile-init.sparc, nothing that we're currently using thinks it's SYSVONLY. I agree that the whole makefile situation is a complete mess, and that autotools isn't much better! I don't know what to do instead.

…

-- Nick

On Jul 24, 2020, at 11:24 AM, Larry Masinter ***@***.***> wrote: #if !defined(LINUX) && !defined(MACOSX) && !defined(FREEBSD) /* these are in the POSIX standard / #define getwd(x) getcwd((x), MAXPATHLEN) #define getrusage(x, y) #define getpagesize() 4096 #endif / LINUX , MACOSX, FREEBSD */ should have && !defined(OS5) added to the other !defined entries -- i believe that Solaris 10 has the POSIX standard functions and doesn't need them defined as they are here. The hardcoding of what is and isn't (or more accurately, was and wasn't) available in the libraries was not particularly well handled at the beginning and then people went and added all kinds of special cases when things didn't compile on new versions of the OS. Sigh. This is one of the things that needs to be cleaned up (and I don't think that GNU Autotools is much better!!) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/Interlisp/maiko/issues/2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWP4IG2XTNVNFEKOGETR5HGUJANCNFSM4PG6UKFA>.

[masinter]

let me try to describe what I was trying to do in my 'cleanup' fork.
-- move unused files to ./unused/ or delete them

• ChangeLog, compile-flags move into README but edit it to describe what these internal notes were talking about
  -- checksum* copy* delete
  -- dbxinit.txt not sure what this is for but we're not using it so move
• DOS? DOS is interesting because it's the only non-X system already working (@Anzus) if we want to go there.
• endiffix ??
• Environment variables we should eliminate them... there is no reason not to do everything with call parameters
• find-writes fixid
• install-medley -- unused
• move makefile-* and usermakefile-* into subdirectory and adjust makeright

Which systems can we drop? systems you can't buy anymore.
leave the files, but move to unused?

[Anzus]

There are a couple of different answers to the DOS/unused question: a) At this point in time the only “legal” version of DOS is the compatibility layer in 32-bit Windows 10. I tried to run Medley there last week, didn’t work. So if you want to run the DOS port, you need to download DOS from somewhere and run it on an emulator like Virtualbox. Medley runs just fine there, but is constrained by the screen resolution. Since we’re not distributing DOS, not our problem on the legality. b) By the same thinking the other “unused” architectures can theoretically be run in QEMU with the appropriate download of an OS. I haven’t tried this yet, but am interested in trying it out to see if I can get one of my older sysouts to load. I’m going to have some more free time in the coming weeks, maybe I’ll try it. Or to put it another way, *everything* that won’t build natively is now a system you can’t buy anymore. I’m of the opinion that keeping them in a historical directory is better than deleting them. That being said, Virtualbox+DOS is waaaay easier to get running than QEMU+SunOS… Arun Welch [email protected]

…

On Sep 3, 2020, at 6:42 PM, Larry Masinter ***@***.***> wrote: let me try to describe what I was trying to do in my 'cleanup' fork. -- move unused files to ./unused/ or delete them ChangeLog, compile-flags move into README but edit it to describe what these internal notes were talking about -- checksum* copy* delete -- dbxinit.txt not sure what this is for but we're not using it so move DOS? DOS is interesting because it's the only non-X system already working ***@***.*** <https://github.com/Anzus>) if we want to go there. endiffix ?? Environment variables we should eliminate them... there is no reason not to do everything with call parameters find-writes fixid install-medley -- unused move makefile-* and usermakefile-* into subdirectory and adjust makeright Which systems can we drop? systems you can't buy anymore. leave the files, but move to unused? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/25#issuecomment-686834725>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBP2DFU2JAZO5ROYIGQFQLSEAZWZANCNFSM4QOKZSZQ>.

[masinter]

@Anzus The historical artifact stuff belongs in the 'history' repository (currently we have https://gitlab.com/masinter/Interlisp).

The goal of this repository (branch) is to create an artifact that Lisp programmers can use and demonstrate, and port to newer environments.

Cleaning up the build process so people can see what's going on is important to reduce the barrier to entry.
I want to give us permission to do things like renaming lde and ldex (why are there two), getting rid of X (to make installing easier). Or packaging the emulator with a sysout so that people could load one thing.

Interlisp as a "residential environment" offers opportunities for more distributed coding styles.

If you have some spare time, I think the webasm port is probably the highest priority. No X, there's an api to JavaScript control of a canvas.

See #18

[masinter]

This is well underway; discussion of "what systems we support" might need documentation.
There are some internal documentation files that should be either merged or referred to by the READMEs

[waywardmonkeys]

Right now, we are keeping support for:

• FreeBSD
• Linux
• macOS
• Solaris

On the CPU side, we assume it is one of:

• x86 (32 bit)
• x86_64
• 32 bit ARM
• 64 bit ARM

However, with most things moving towards assuming POSIX, the odds are that we're actually able to run on more than that with fairly little work. I don't think there's much of anything (if anything at all) that seriously prevents us from running on mingw, cygwin, RISC-V, etc. Probably just a bit of work.

The DOS code is being kept around for now, as well as code for SunOS 3 and 4 and some of the old 386 code that is flagged for ISC.
The SunOS 3 and 4 code doesn't likely compile. The DOS code is in an entirely unknown state. Most of this is to have a reference for some of the things that aren't currently working but that we might want to bring back like some of what was done in inline assembly on 386.

[nbriggs]

You left out CPUs: SPARC (in both 32 and 64 bit mode; sparcv8plus and sparcv9 are both targets I compile for most days) and PowerPC because I run the code on a Mac PowerBook G4, though not every day.

[waywardmonkeys]

Along these lines, it is worth noting that many of our bits of platform dependent code, apart from DOS and some Solaris bits, are in the process of going away or already removed. Without platform-specific things, a lot of the build system can be simplified.

(In fact, I maintain for myself a small build file for cmake that lets me build much faster / reliably (proper incremental builds) as well as giving me access to running tools like clang's static analyzer.)