On Sun, Nov 16, 2003 at 05:17:00PM +0100, Michel Schinz wrote:
> Le 15 nov. 03, à 05:23, Anthony Carrico a écrit :
> >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...
Are you talking about easier for the user or the developer?
> 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)...
Wait a minute; that doesn't provide any consistency for the user (or
operating system level packager). In theory, they have no idea that
the application/library that they are installing has anything to do
with scsh. Maybe they had never heard of scsh before configure told
them it was required for the application/library at hand.
> ...and that, once installed, these packages can be used with a
> standard procedure (which, currently, is "add -ll <package>/pkg.scm
> to your script").
Yes, this is the pay-off for us developers, most users won't see this.
> 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.
Exactly. A standand trivial Makefile could be provided for scsh
developers to use as the user interface. Or after the configure shell
script finds scsh, it could call a scsh script and use your tools to
automatically create a Makefile with the install/uninstall user
interface.
> >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".
What if scsh (or the correct version) isn't installed on the machine?
In this case, it is the configure script's job to tell the user about
the problem. I'm not saying that we need a sophisticated configure
script immediately, but we should leave the hooks there for
professional quaility in the future.
> >Also, the makefile may do the right thing with other components (like
> >documentation, etc.).
>
> 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 understand your frustration. In my last message I said that I
thought the the Makefile install/uninstall user interface was an
unfortunate accident of history, but it is easy enough to comply with
this interface, and it would provide our users with a standard
install/uninstall experience.
> 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.
Thank you very much.
> 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
> role).
Ok.
"Shall we try an iteration of the current packaging proposal for the
major scsh libraries?"
I vote yes! It is good for everybody, and since we are few, we can
make a change later if we find trouble.
"Shall we design our own user interface for installation and
uninstallation, or shall we follow the gnu coding standards
(configure, make install, and make uninstall)"
I vote for "configure, make install, and make uninstall". It is
standard and easy to achieve (even if it seems silly to use a trivial
Makefile for simple libraries). Developers who are committed to the
standards won't be forced to choose between them and the scsh
conventions.
--
Anthony Carrico
|