Le 15 nov. 03, à 05:23, Anthony Carrico a écrit :
On Fri, Nov 14, 2003 at 05:17:54PM +0100, Michel Schinz wrote:
Well, my main reason was that I did not see a reason for following
them. I think these conventions are indeed well established for
stand-alone packages (like scsh itself) but not for add-on packages.
I guess I don't see much reason for an installation difference between
apps and libraries.
I think the reason for the difference is that when you install
libraries for something, be it Perl, Python or scsh, you can be sure
that the something in question is installed on the target system. You
can therefore use it instead of plain shell scripts to perform
installation, which is supposedly easier. At least that's what I would
claim for scsh, and my limited experience tells me that it's mostly
true, with a few exceptions: doing the equivalent of "cat", "cp" or
even "find" is still a bit too painful from scsh right now, but that
will hopefully change in the future (I know about "run" of course, but
I'd like to do without for such basic things).
I don't mind breaking conventions if there is a reason, but if there
isn't a good reason, why not follow them? Let's face it -- building
and installing unix software was a complete disaster in the 90's, now
it's getting pretty easy thanks to the people who set and followed
I agree that it's a lot easier today, but my impression is that it's
mostly due to autoconf, which checks characteristics about the system
and then performs substitutions accordingly in various files. That was
the hard part.
In my opinion saying that scsh packages are installed with a different
command than "make install" is not such a big deal. What's important is
that this installation procedure is consistent (i.e. all scsh packages
can be installed using the very same command) and that, once installed,
these packages can be used with a standard procedure (which, currently,
is "add -ll <package>/pkg.scm to your script").
What we could imagine to make things a bit more standard is to launch
the scsh installation script from a Makefile. Currently there's an sh
script called "install" which launches scsh, but this could also be
done by a (trivial) Makefile. To pass arguments (like the location of
the package root) one would use make variables. The following Makefile
illustrates what I mean:
SCSH = scsh
$(SCSH) -lm install-pkg.scm -m install -e install-main -s
(it's really kludgy BTW, especially the use of /dev/null, but it's just
to illustrate my point). With this Makefile, one can say e.g. "make
install ROOT=/tmp/root" to install a package in /tmp/root.
I have to say I prefer the other solution because passing parameters
(especially boolean ones like the current "--inactive") is easier, but
the above could work.
Anyway, I think there may be complicated installations that will want
to take advantage of more advanced configuration and makefile features
(maybe they have components in languages other than scsh).
I agree completely here, but my view was the following: most packages
won't need autoconf because they will be pure Scheme. Therefore, let's
make the standard case easy. For packages which do need autoconf, it
can be invoked from the scsh script with a simple "run".
Also, the makefile may do the right thing with other components (like
Well, my impression is that using "make" to perform installation is
overkill. The main feature of make is that it can detect which files
are out of date and rebuild just these. This is indeed useful during
development, when files do get changed, but for the installation part,
I don't think it's needed. Most makefiles used to install software
contain only "phony" rules (like my "install" rule above) which are
little more than subroutines. At least that's how I view this.
My conclusion is that makefiles, when used to install a piece of
software, are little more than glorified shell scripts. Writing them in
scsh should therefore be at least as easy, and hopefully easier.
I don't claim that the small library I posted here earlier is the
definitive solution to writing installation scripts. It has some
problems I'm aware of, and I'm sure people will find more. But I hope
that with a bit of work we can get to the point where it will make
writing installation scripts *a lot* easier than using make and sh.
I think it is cool that you are making scsh native tools to help with
installation, but of course there are probably many ways to conform to
the Proposal. As for Sunterlib, the quickest way would probably be to
make a quick change to the install part of its makefile.
My understanding of the proposal is that it should include the command
one has to launch to install the package. If we settle for "make
install" then indeed a simple change to the current Makefile would do
the trick. If we settle for something else, I think we should use the
new standard for all scsh packages, sunterlib included. (That's a
suggestion, not an order, of course).
Anyway, in order to test my system I have written a package definition
for sunterlib. Whatever decision is taken in the end, I will adapt it
to the "official" system and send it to you.
This makes me think that we have to find a way to take decisions for
this packaging stuff. Until now it seems to me that most design
decisions for scsh were taken through a mixture of consensus and
unilateral decisions from the authors. For this packaging proposal, we
should either start to vote on some points or let one "benevolent
dictator" choose (Martin or Mike being the obvious candidates for the