Hi David et al,
While experimenting with some of the recent PolyML commits, I realised the
build system doesn’t seem to set any particular C++ standard. I guess this
results in the compiler default (e.g. GNU++14 in the latest GCC [0]). Is this
intentional?
Relatedly, coming up on 2018 it
On 15/12/2017 18:41, Makarius wrote:
On 15/12/17 17:46, David Matthews wrote:
On 15/12/2017 16:15, Makarius wrote:
* The polyc script cannot handle directory names with spaces, e.g. the
main "prefix".
I guess it would need some extra quotation. Do you want to propose a fix?
See the
On 15/12/2017 16:15, Makarius wrote:
On 12/12/17 14:14, David Matthews wrote:
The polyc script has been developed mainly to simplify the linking of an
exported ML function and in particular to try to capture the libraries
that need to be included. I've been having another look at this because
There seems to be a problem with building it as a shared library in
FreeBSD. It seems to work fine with
./configure --disable-shared
David
On 15/12/2017 12:58, Kostirya wrote:
It is broken. I think this is because of the inconsistency of the
options: -nostdlib and -lstdc++.
libtool: link:
On 12/12/17 14:14, David Matthews wrote:
> The polyc script has been developed mainly to simplify the linking of an
> exported ML function and in particular to try to capture the libraries
> that need to be included. I've been having another look at this because
> of an issue that was reported a
Thanks. It was a code-generator problem that only showed up because of
a change elsewhere. It should now be fixed.
David
On 14/12/2017 13:17, Kostirya wrote:
Hello.
Poly/ML broken on FreeBSD i386 (clang version 3.8.0).
./polyimport polytemp.txt -I . < ./exportPoly.sml
Use:
