bryan@geo-works.UUCP (Bryan Ford) (06/26/89)
In article <132@ra.abo.fi>, rosenber@ra.abo.fi (Robin Rosenberg INF) writes: >Bryan suggests we use a 'mountlist' to install programs. I suggest a >'make-file' instad. >Why a makefile then? The problem is that sometimes when you are about to >do something you have to do something >else first. ... Good idea! Actually, the two formats could be merged very easily. For example, say program 'blah' depends on program 'blee' to be run first: blah: blee <parameters> # blee: <parameters> # This way the 'Start' program could figure out dependencies and run programs in the right order. The main difference would be, with this, ALL listed programs will get run, while with Makefiles, only ones that depend (directly or indirectly) on the first one will get run. In other words, the dependencies only tell the *order* in which things get run, not whether or not to run the programs. As I said before, this would not be good for a do-it-all, highly customizible startup sequence (we already have one of those, the Startup-Sequence). However, it would provide an easy way to install and run programs without making the user do lots of work. Another option would be to do something like Commodore did with the 'Expansion' directory. Just have a 'Startup' directory, and a program similar to BindDrivers that would find all the icons in this directory and run the programs as necessary. This way, a user could 'install' a program by simply dragging the icon into the 'Startup' directory, and all the parameters could be in the .info file. >ISSUE#2: Setting program parameters. >Programs that have parameters to change should have an intuition program to >to that. The program should be callable from the main preferences program >so we can set *all* parameters from essentially the same place. The preferences >program could store the parameters in the makefile along with the rules >for running the program. Another good idea! How about this. Each (conforming) program would include a separate setup program (with its own icon) that the user just drags into the Prefs directory. The main Preferences program would search the directory for other icons and put them in a menu, and when the user activates one of the menus, Preferences simply boots the program like a normal Workbench program. That way the user could activate that particular setup program directly as well, by clicking on its icon from Workbench. ISSUE#3: 'Assign's Lots of programs require their own 'assign'ed directories, and, like startup-sequences, these work only from the CLI. How about using Dave Haynie's BindNames program? The program's install or setup program could simply write all required assigns (relative to a directory specified by the user) to its own 'names' file in the SYS:Names directory. Since BindNames automatically goes through every file in the SYS:Names directory, this would be quite simple. Also, an icon for the Names directory and for the program's 'names' file would be good, so the user could delete the thing if and when he deletes the program itself. Bryan -- ____________________________________________ _/ Bryan Ford - bryan@geo-works.geo-works.com \_ _/ ..!utah-cs!caeco!i-core!geo-works!bryan \_ / ..!uunet!iconsys!caeco!i-core!geo-works!bryan \
limonce@pilot.njin.net (Tom Limoncelli) (06/28/89)
Wouldn't it be difficult to write a program that would insert
something into a makefile?
I think that with 1.3, it is not all that difficult to have programs
that install onto a hard drive. With IconX and ASSIGN MYPROG$$: ""
one can do most anything, no it's not perfect.
Why are all the developers and C-A quite on this topic? Is some
secret "install-o-matic" gonna be in 1.4? Maybe using ARexx?
Alas, we can but wait.
_Tom_
--
Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net
Drew University -- Box 1060, Madison, NJ -- 201-408-5389
Standard Disclaimer: I am not the mouth-piece of Drew University