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