On 11/04/2013 11:44, Makarius wrote:
On Thu, 11 Apr 2013, David Matthews wrote:
I misunderstood the motivation for polyc. I thought that it was to
allow those without compiling/linking knowledge to easily build
executables, i.e. to de-skill the process. Whilst such users may
realize that
./configure --prefix <non-standard location>
requires
PATH=${PATH}:${bindir}
they would not realize that they need (assuming no super-user
privileges)
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${libdir}
I just wonder how common that case is.
Perhaps I'm wrong. I guess if there was a simple, portable way of
sorting out the paths I'd consider it.
From some of the comments on this thread I had the idea that there were
potential users of Poly/ML out there who were put off by the
read-eval-print-loop. After all, that isn't the way most other
programming languages/implementations work. Having the --script option
allows those used to scripting to code something up quickly so that's
one group catered for. Another group of potential users are those used
to the compile-link-execute model and that was the group I was trying to
target with the polyc script.
For the Isabelle distribution (which includes a multi-platform Poly/ML
version) we do exactly the opposite quite sucessfully for > 5 years: the
many different package managers of the many different operation system
distributions are ignored as much as possible.
I have seen so many good programs turned into bad packages, not just
Poly/ML.
I have also suffered from bad Poly/ML packages but I feel I would rather
help get the packages fixed than discourage them. Isabelle and Poly/ML
are rather different both in the complexity and in the motivation of
potential users.
The most elementary wrapper script for standalone ("portable") Poly/ML
directories is included in the attachment. The real one for Isabelle is
more advanced. Next time I will consider "./configure
--disable-shared", which I did not know before.
I wonder if --disable-shared should be the default with ./configure. It
would solve a lot of these problems. I can see that packagers who are
going to build a package to install to the standard location would want
to build the shared library but users building a stand-alone system
probably don't want it. If you're only building "poly" anyway there's
no saving by having libpolyml as a separate library.
David
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
