> In principle, PAKCS should also run under Windows since it
> is based on ghc for the front-end and (SWI/Sicstus) Prolog
> for the back end, and both are also available for Windows.
that sounded promising - it is always better to avoid platform
dependencies than to "depend on unix/windows now, hoping
to port to windows/unix later". projects depending on unix
tricks substantially increase the efforts needed for porting,
while projects avoiding unix dependencies often can be made
to build and run on windows with surprisingly little extra effort
(because others have done the work of porting the tools we use).
cygwin used to pretend there were no differences, but it is no
longer safe to depend on that extra layer alone, as more and
more dependencies have "gone native" (such as ghc, prolog, ..).
i happen to have an old SWI prolog and lots of ghc's installed,
so i gave it a try. perhaps this is of interest to other Curry
developers, as well.
with most of the functionality left to ghc/swip, the main source
of trouble are absolute paths in the build system. both ghc and
swip are native windows apps, so they expect native windows
paths and know nothing about unix/cygwin-style '/usr/whatever'
or '/cygdrive/c/here'.
avoiding this pitfall generally just takes some discipline: relative
paths are fine, but things like 'pwd' become dangerous, as they
return absolute, cygwin-style, paths; the tool to the rescue, if
one needs to use absolute paths, is 'cygpath':
http://www.cygwin.com/cygwin-ug-net/using-utils.html#cygpath
in particular, 'cygpath -m `pwd`', converts to a mixed style,
windows paths with forward slashes, which many tools can
handle.
another typical source are 'system'-style calls: on windows,
and from within windows-native apps, like ghc-compiled
haskell or swip prolog code, their equivalents can not rely
on a unix-style shell. the command to run is either passed
to some barebones exec-style function, or at best to one
of the windows shells. for runtime calls, unixisms of all kind
should be avoided whenever possible, for the buildsystem,
since it tends to rely on cygwin tools anyway, one can
explicitly call the cygwin bash.
since pakcs calls a shell script that calls prolog that calls
shell scripts, a runtime dependency on cygwin seems hard
to avoid.. on the other hand, everything seems to be routed
via a single shell script wrapper, so there wouldn't be much
to change.
if i just convert the paths, and make prolog call 'bash' (see
diff.txt), 'make' gets to the point where 'bin/pakcs' is first
called, on 'AllSolutions'. but then it keeps throwing prolog
code at me, in what is probably not a feature? a short
excerpt from 'make.log' is appended.
any suggestions on what might trigger this behaviour?
prolog system upset? other unixisms/shell assumptions i
should have a look at?
claus
..
rm -f AllSolutions.pl && `pwd`/../bin/pakcs -c AllSolutions
blocked_hnf(_G3196, _G3196, _G3205, _G3205).
%%%%%%%%%%%% clauses for generic operations %%%%%%%%%%%%%%%%%%%
constrEq(_G18330, _G18331, _G18332, _G18333, _G18334):-freeze(_G18333,
blocked_constrEq(_G18330, _G18331, _G18332, _G18333, _G18334)).
blocked_constrEq(_G18443, _G18446, _G18449, _G18452, _G18455):-hnf(_G18443,
_G18467, _G18452, _G18497), hnf(_G18446, _G18470, _G18497, _G18476),
constrEqHnf(_G18467, _G18470, _G18449, _G18476, _G18455).
constrEqHnf(_G18591, _G18592, _G18593, _G18594, _G18595):-freeze(_G18594,
blocked_constrEqHnf(_G18591, _G18592, _G18593, _G18594, _G18595)).
blocked_constrEqHnf(_G18638, _G18641, _G18449, _G18452,
_G18455):-var(_G18638), !, bindTryNf(_G18638, _G18641, _G18449, _G18452,
_G18455).
blocked_constrEqHnf(_G18641, _G18638, _G18449, _G18452,
_G18455):-var(_G18638), !, bindTryNf(_G18638, _G18641, _G18449, _G18452,
_G18455).
blocked_constrEqHnf(_G18786, _G18789, 'Prelude.success', _G18452,
_G18455):-number(_G18786), !, _G18786=_G18789, _G18452=_G18455.
blocked_constrEqHnf(_G18443, _G18446, _G18449, _G18452,
_G18455):-functor(_G18443, _G18990, _G18965), functor(_G18446, _G18997,
_G18998), _G18990==_G18997, _G18965==_G18998, !, genConstrEqHnfBody(1,
_G18965, _G18443, _G18446, _G18974), hnf(_G18974, _G18449, _G18452, _G18455).
genConstrEqHnfBody(_G19026, _G18965, _G19032, _G19035,
'Prelude.success'):-_G19026>_G18965, !.
genConstrEqHnfBody(_G19026, _G18965, _G18443, _G18446, 'Prelude.=:='(_G19125,
_G19128)):-_G19026=_G18965, !, arg(_G19026, _G18443, _G19125), arg(_G19026,
_G18446, _G19128).
genConstrEqHnfBody(_G19026, _G18965, _G18443, _G18446,
'Prelude.&'('Prelude.=:='(_G19125, _G19128), _G19241)):-arg(_G19026, _G18443,
_G19125), arg(_G19026, _G18446, _G19128), _G19274 is _G19026+1,
genConstrEqHnfBody(_G19274, _G18965, _G18443, _G18446, _G19241).
bindTryNf(_G18638, _G19327, _G18449, _G18452, _G18455):-nf(_G19327, _G19363,
_G18452, _G18497), (nonvar(_G18497)->bindDirect(_G18638, _G19363, _G18449,
_G18497, _G18455);bind(_G18638, _G19327, _G18449, _G18452, _G18455)).
bindDirect(_G18638, _G19327, _G18449, _G18452, _G18455):-var(_G19327), !,
_G18638=_G19327, _G18449='Prelude.success', _G18452=_G18455.
bindDirect(_G18638, _G19327, _G18449, _G18452, _G18455):-occursNot(_G18638,
_G19327), _G18638=_G19327, _G18449='Prelude.success', _G18452=_G18455.
bind(_G18638, _G19327, 'Prelude.success', _G18452, _G18455):-var(_G19327), !,
_G18638=_G19327, _G18452=_G18455.
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Mai 09 2007 - 08:48:45 CEST