$ grep -r PACKAGE_VERSION *
Setup.lhs:  let args = ("-DPACKAGE_VERSION=" ++ show' version) :
src/hscurl.c:  "darcs/" PACKAGE_VERSION " libcurl/" LIBCURL_VERSION;
src/HTTP.hs:headers =  [Header HdrUserAgent $ "darcs-HTTP/" ++
PACKAGE_VERSION]

At least under Windows this is wrong, because PACKAGE_VERSION is not a
string, e.g. is 2.4.1 instead of "2.4.1".

Prevents building (cabal install darcs) under Windows CMD.EXE.

For what it's worth I've encountered this problem too (on Linux), but
had assumed it was caused by something I did because noone else was
complaining and it seems like the kind of thing that should fail
consistently.

I have never seen such problems. Current darcs builds fine for me on linux.

Can you please post the errors?

c:\Sources>cabal unpack darcs-2.4.1
Unpacking to darcs-2.4.1\

c:\Sources>cd darcs-2.4.1

c:\Sources\darcs-2.4.1>cabal configure -f-curl -w ghc-6.10.4.exe
Resolving dependencies...
Configuring darcs-2.4.1...
c:\Sources\darcs-2.4.1>cabal build
[..lots of builds..]
[ 41 of 142] Compiling HTTP             ( src\HTTP.hs, dist\build\HTTP.o )

src\HTTP.hs:34:51:
    Couldn't match expected type `[Char]'
           against inferred type `a -> c'
    In the second argument of `(++)', namely `2.4 . 1'
    In the second argument of `($)', namely `"darcs-HTTP/" ++ 2.4 . 1'
    In the expression: Header HdrUserAgent $ "darcs-HTTP/" ++ 2.4 . 1
C:\ghc\ghc-6.10.4\bin\ar.exe: dist\build\Darcs\ArgumentDefaults.o: No
such file or directory

Vista, 32bit
c:\Sources\darcs-2.4.1>ghc-6.10.4.exe --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4
c:\Sources\darcs-2.4.1>cabal --version
cabal-install version 0.8.0
using version 1.8.0.2 of the Cabal library

HTH

That's odd.  We have three variables to try here (so far)

1. Windows [but Ganesh has seen this on Linux]
2. -f-curl [no luck on Linux]
3. cabal-install version (mine is 0.8.2)

Gracjan: could you try upgrading cabal-install?  (I doubt this will make
a difference if you're using the same Cabal library, but maybe?).  Also
cabal build -v2 may be useful.

Thanks,

1. Building under both CMD.EXE and MSys fails with same error message.
2. Build -fcurl and -f-curl fails with the same error message but in
different files (src/HTTP.hs vs src/hscurl.c).
3. Upgraded to cabal-install-0.8.2, made no difference.

I'm compiling under ghc-6.10.4 as ghc-6.12.1 does not like regex-posix
at all (regex-posix does not compile after reasonable amount of tries).

cabal build -v2 excerpts:

 c:\Sources\darcs-2.4>cabal build -v2
 Creating .\dist\setup (and its parents)
 .\dist\setup\setup.exe build --verbose=2
 darcs changes --from-tag 2.4 --count
 Creating dist\build\autogen (and its parents)
 darcs changes --from-tag 2.4
 Creating dist\build (and its parents)
 Creating dist\build\autogen (and its parents)
 Preprocessing library darcs-2.4...
 Preprocessing executables for darcs-2.4...
 Building darcs-2.4...
 Building library...
 Creating dist\build (and its parents)
 C:\ghc\ghc-6.10.4\bin\ghc-6.10.4.exe --make -package-name darcs-2.4
-hide-all-packages -no-user-package-conf -i -idist\build -isrc/win32
-isrc -idist\build\auto gen -Idist\build\autogen -Idist\build
-Isrc/win32 -Isrc -optP-DPACKAGE_VERSION="2.4"
-optP-PACKAGE_VERSION_STATE="release" -optP-DHAVE_HTTP -optP-DUSE_COLOR
-optP-DHAVE_MAPI -optP-DWIN32 -optP-DHAVE_HTTP -optP-include
-optPdist\build\autogen\cabal_macros.h -odir dist\build -hidir
dist\build -stubdir dist\build -package HTTP-4000.0.9 -package
array-0.2.0.0 -package base-3.0.3.1 [and rest of -package and -X options
and the source modules follow]

HTH,
Gracjan

So as a workaround, you could replace PACKAGE_VERSION by hand.

Gracjan, would you be willing to try and minimise this for us?  For
example, could you see what happens when you run that ghc --make command
line by hand? (it may simplify things if you cut out the
--hide-all-packages so that you don't have to specify the packages). 
Maybe try to to have a trivial hello-world type program?  Just trying to
farm out the darcs jobs as much as possible ;-)

pkgver.hs:
 {-# LANGUAGE CPP #-}
 main = print PACKAGE_VERSION

 c:\Sources>ghc --make -DPACKAGE_VERSION="1.2.3" pkgver.hs -fforce-recomp
 [1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )

 pkgver.hs:2:7:
    Couldn't match expected type `b -> c' against inferred type `IO ()'
    In the first argument of `(.)', namely `print 1.2'
    In the expression: print 1.2 . 3
    In the definition of `main': main = print 1.2 . 3

The above is kind of obvious since I'm running this from CMD shell.

 c:\Sources>ghc --make -DPACKAGE_VERSION=\"1.2.3\" pkgver.hs -fforce-recomp
 [1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )
 Linking pkgver.exe ...

 c:\Sources>pkgver.exe
 "1.2.3"

So the backslashed version works.

HTH

Duncan,

Is there a known Cabal issue (or System.Process) about quotes not
being escaped for the GHC command line on Windows?  See below.

We have a workaround for our Haskell modules (using our
dist/build/autogen/Version.hs), but I couldn't work out how to make the
equivalent workaround for our C modules (our "version.h" did not get picked up,
perhaps some -I we need to pass to GHC/GCC somewhere)

> pkgver.hs:
>  {-# LANGUAGE CPP #-}
>  main = print PACKAGE_VERSION

Bad:
 
>  c:\Sources>ghc --make -DPACKAGE_VERSION="1.2.3" pkgver.hs -fforce-recomp
>  [1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )
> 
>  pkgver.hs:2:7:
>     Couldn't match expected type `b -> c' against inferred type `IO ()'
>     In the first argument of `(.)', namely `print 1.2'
>     In the expression: print 1.2 . 3
>     In the definition of `main': main = print 1.2 . 3

Good:

>  c:\Sources>ghc --make -DPACKAGE_VERSION=\"1.2.3\" pkgver.hs -fforce-recomp

[Works fine]

Gracjan, Nice and obvious.  Thanks!

Patch224 should resolve the issue for your -f-curl case.  Seems like we could
do something similar for the C module hscurl.c though...


-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Food for thought:

TL;DR: use rawSystem in place of system.

c:\Sources>ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/  :? for help
Prelude> :m +System.Process
Prelude System.Process> system "ghc --make -DPACKAGE_VERSION=\"1.2.3\"
pkgver.hs -fforce-recomp"
[1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )

pkgver.hs:2:7:
    Couldn't match expected type `b -> c' against inferred type `IO ()'
    In the first argument of `(.)', namely `print 1.2'
    In the expression: print 1.2 . 3
    In the definition of `main': main = print 1.2 . 3
ExitFailure 1
Prelude System.Process> system "ghc --make
-DPACKAGE_VERSION=\\\"1.2.3\\\" pkgver.hs -fforce-recomp"
[1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )
Linking pkgver.exe ...
ExitSuccess
Prelude System.Process> rawSystem "ghc" ["--make",
"-DPACKAGE_VERSION=\"1.2.3\"", "pkgver.hs", "-fforce-recomp"]
[1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )
Linking pkgver.exe ...
ExitSuccess
Prelude System.Process>


Although I don't really know where deep inside cabal is the call to
system that should be changed to rawSystem.

On Tue, 2010-04-27 at 17:46 +0000, Gracjan Polak wrote:
> Gracjan Polak <gracjanpolak@gmail.com> added the comment:
> 
> Food for thought:
> 
> TL;DR: use rawSystem in place of system.

Note that Cabal/cabal-install does not use system anywhere for exactly
this reason.

So sadly the problem is not quite that simple.

If you run cabal with -v3 it shows you unambigiously (using Haskell
'show' syntax) how it is invoking programs, eg:

("/usr/bin/ghc", ["-v","--make","./Setup.lhs",
"-o","./dist/setup/setup","-odir","./dist/setup","-hidir","./dist/setup", "-i","-i.","-package","Cabal-1.8.0.2"])

For your use case we would expect the argument to be printed as:

"-DPACKAGE_VERSION=\"1.2.3\"" if it's correct, or
"-DPACKAGE_VERSION=1.2.3" if it's wrong.

In my brief testing, cabal looks to be doing it correctly. That is,
given a line in the .cabal file like:

cpp-options: -DBLAH="foobar"

then cabal calls ghc with the argument (formatted here in unambigious
Haskell show syntax) "-optP-DBLAH=\"foobar\""

Since it uses rawSystem (or a variant like runProcess) that takes
individual [String] args, there is no shell escaping/interpretation
going on. Those strings are exactly what are passed as the args vector.

What's possible is that cpp is eating the ""s in the argument. That
might explain why it doesn't happen for everyone. You'll need to find
someone who can reproduce this problem and investigate.

Duncan

Relevant line from

cabal build -v3

is

("C:\\ghc\\ghc-6.10.4\\bin\\ghc-6.10.4.exe",["--make","-package-name","darcs-2.4.1","-v","-hide-all-packages","-no-user-package-conf","-i","-idist\\build","-isrc/win32","-isrc","-idist\\build\\autogen","-Idist\\build\\autogen","-Idist\\build","-Isrc/win32","-Isrc","-optP-DPACKAGE_VERSION=\"2.4.1\"","-optP-DPACKAGE_VERSION_STATE=\"release\"","-optP-DHAVE_HTTP","-optP-DUSE_COLOR","-optP-DHAVE_MAPI","-optP-DWIN32","-optP-DHAVE_HTTP","-optP-include","-optPdist\\build\\autogen\\cabal_macros.h","-odir","dist\\build","-hidir","dist\\build","-stubdir","dist\\build",..all
-packages..,"-O","-Wall","-O2","-funbox-strict-fields","-fwarn-tabs",..all
-Xs..,..all modules..])

Looks correct wrt doublequotes for me. What happens with this array later?

> Looks correct wrt doublequotes for me. What happens with this array later?

As a guess: C Runtime eats some of it.  C runtime from mingw (actually
Microsoft's) supports filenams with spaces this way, iirc, and ghc
uses the C runtime entry point and main, iirc.  But I could be wrong or
misunderstood the problem.

Can somebody explain the following:

Prelude System.Process> rawSystem "ghc.exe" ["--version"]
The Glorious Glasgow Haskell Compilation System, version 6.12.1
ExitSuccess

Prelude System.Process> rawSystem "ghc.exe" ["--make",
"-DPACKAGE_VERSION=\"1.2.3\"", "pkgver.hs", "-fforce-recomp"]
[1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )
Linking pkgver.exe ...
ExitSuccess

Prelude System.Process> rawSystem "ghc-6.12.1.exe" ["--make",
"-DPACKAGE_VERSION=\"1.2.3\"", "pkgver.hs", "-fforce-recomp"]
[1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )

pkgver.hs:2:7:
    Couldn't match expected type `b -> c' against inferred type `IO ()'
    In the first argument of `(.)', namely `print 1.2'
    In the expression: print 1.2 . 3
    In the definition of `main': main = print 1.2 . 3
ExitSuccess

Seems cabal -w flag activates a bug in ghc/ghc-6.12.1 interaction.

Prelude System.Process> rawSystem "ghc-6.10.4.exe" ["--make",
"-DPACKAGE_VERSION=\"1.2.3\"", "pkgver.hs", "-fforce-recomp"]
[1 of 1] Compiling Main             ( pkgver.hs, pkgver.o )

pkgver.hs:2:7:
    Couldn't match expected type `b -> c' against inferred type `IO ()'
    In the first argument of `(.)', namely `print 1.2'
    In the expression: print 1.2 . 3
    In the definition of `main': main = print 1.2 . 3
ExitSuccess

Wrapper executable for ghc-x.y.z
(see http://darcs.haskell.org/ghc-6.12/ghc/driver/ghc/ghc.c )
flattens the commandline.  Hmmm.  I can't see out of hand
exactly what happens.  But it might be something to do with
this.

Created a ghc ticket and attached a patch there that fixes this
particular issue:

http://hackage.haskell.org/trac/ghc/ticket/4037

Hopefully it gets accepted upstream.

The following patch updated the status of issue1824 to be resolved:

* Resolve issue1824: avoid PACKAGE_VERSION under Windows. 
Ignore-this: 289a827c98ba3b286404e4af6d8ada4c
There's some quoting issue passing the PACKAGE_VERSION string via the CPP.
This seems to affect Windows, so we'll just skip around the issue until
(presumably) Cabal/cabal-install are fixed.

Note that this is resolved as far as *darcs* is concerned.
See the GHC ticket for upstream status.

The following patch updated issue issue1824 with status=resolved;resolvedin=2.5.0 (current)

* Resolve issue1824: avoid PACKAGE_VERSION under Windows. 
Ignore-this: 289a827c98ba3b286404e4af6d8ada4c
There's some quoting issue passing the PACKAGE_VERSION string via the CPP.
This seems to affect Windows, so we'll just skip around the issue until
(presumably) Cabal/cabal-install are fixed.