On Mon, Nov 17, 2003 at 09:43:42AM -0500, Andreas Bernauer wrote:
> Anyhow, on every major system there is package manager of some kind
> that takes care of uninstalling (thus, I don't have to keep all the
> config files floating around just in case I want to uninstall
> something later)...
I agree. They will be primary consumers of whatever interface we
> ...and on systems that lack this package manager there are
> administrators who are sophisticated enough to deal with
> non-standard install/uninstall procedures.
Sophisticated yes, but I think it is polite for us not to make them
learn an interface different than what they expect.
> I am not sure if it is a good idea to carry on with something just
> because it's been done that way for a long time...
I agree in the abstract, but I disagree about scsh specifically. Scsh
is not a leading edge system abandoning all tradition. Scsh is a
Scheme geared toward traditional Unix programming.
> ...configure and make do a good job for C files as C files are
> heavily architecture dependant. This is not the case for scsh
> (Except for the floating points? :-).
I think that most distributions involving scsh will be applications
that involve components other than just scsh libraries. I think there
will be scsh scripts which will need to go into binary directories. I
think there will likely be components in other languages (including C)
or will need to integrate with other systems (XML catalogs, etc.). Who
can say exactly what role scsh will play in some killer application?
Because of this I think the neutral ground is valuable.
> I don't see a reason to use make, except for tradition.
I don't either, I just don't see a reason to invent our own interface.
> Make is good to compile C source files but doesn't make sense to me
> for scsh source files.
Scsh is not a desert island. I don't think you can separate the scsh
issues from C source file issues -- they are tied together in the
context of Unix.
> The only thing that should be covered in one way or another (in the
> future) are dependencies, e.g. among scsh libraries,...
Correct. A configure script could use scsh to analyze the package
> ...and make is not made for this.
We don't currently have any compiling to do, so we have no compilation
dependencies, but that may change if we ever go to byte-code, so why
not plan for the future? (or is someone implementing "make" in scsh?)
> We would use make as a host for (bash!?) shell scripts.
Not exactly, we would either:
1. Use an sh script ("configure") to call a scsh script
("configure.scm") to create a Makefile that would host scsh shell
scripts for install/uninstall.
Since this method could use Michel Schinz's original package
scripts without change. I'll attach an example "configure" and
"configure.scm" for this method to this message.
2. Use an sh-configure-script to call a scsh-configure-script to
create a Makefile that installs the files with the 'install'
In the future, we could move to this method by modifying Michel
Schinz's original package scripts to generate lists of
files, instead of actually creating the directories and
copying the files. One advantage of this method is that these lists
might make the Makefile look more meaningful to downstream (debian,
redhat, etc.) maintainers, and might be useful for bytecode
compilation in the future (wishful thinking).
Description: Text document
Description: Text document