On 11/04/13 16:11, David Matthews wrote:
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.
Maybe this is just something to be prominently documented in
installation instructions!
I am also wondering whether libtool helps. I know very little about it
though.
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.
Understand. I think I probably came up with a different group based on
what I thought a Python programmer may typically know. I don't have any
experience with Python though nor any Python compilers (if such things
exists).
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.
If, in future, people are building Poly/ML-based applications, I think
it would be preferable for the default to be dynamic. For example, I
have just tried building the (SML!) GTK+ Hello World demo: the
executable is much larger with static linking (768k with -ggdb, 560k
stripped) than with dynamic linking (160k, 148k).
The default linking method is quite a significant decision because, if I
understand correctly, it fixes the way Poly/ML-based applications are
linked, i.e. it is not possible to choose the linking method (to
Poly/ML) when building a Poly/ML-based application. Is that correct?
(I am intrigued to know why.)
Phil
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
