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.
> http://www.haskell.org/libraryInfrastructure/proposal/, an interesting
I'm looking at the table of contents. It looks useful, thanks.
> Anthony Carrico <firstname.lastname@example.org> writes:
> > Is there any reason not to follow these conventions?
> Do you think that using make would be a good idea because it is
> standard, or because you think that make's features are important to
> have in build/install scripts?
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
It is unfair that the "make *" part of this standard isn't agnostic
(just a shell script, like the configure part), but it's too late to
argue about that, right?
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). Also, the
makefile may do the right thing with other components (like
documentation, etc.). I can't think of a reason the simple case
couldn't use the standard interface too. It makes one less new thing
for people to learn.
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.