-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.4.1 build failure with cpphs 1.18.2: Cannot parse #if directive #3
Comments
That's very strange, because the only change between 0.4 and 0.4.1 is in the Cabal file, informing it to use cpphs. So while I could possibly imagine there being a change between cpphs 1.18.1 and 1.18.2 which causes it to stop working for this code (which would be unfortunate), I can't possibly imagine what could cause the same version of cpphs to have different results with version 0.4 versus 0.4.1 of this package. Are you sure that's actually the case, and it's not some other issue such as the Cabal file change causing it to select different cpphs versions or different cpp implementations entirely, and/or some issue which causes ghc-pkg to see one version of cpphs while another is being actually found in the PATH, or something of that nature? |
I didn't notice that type-eq 0.4 does not use cpphs at all. However, I've tested type-eq-0.4.1, and:
I've also additionally checked if correct cpphs is used by removing execute bit from file permissions ("forbidden" during compilation confirms that $HOME/.cabal/bin/cpphs was used) and by manually checking file modification time. I've noticed one more thing: changelog included in package at Hackage mentions change in 1.18.2, but changelog at cpphs' source repository does not: http://code.haskell.org/cpphs/CHANGELOG First one starts with:
and second one starts with:
The "bugfix for erroneous boolean intepretation of some macro expansions in #if clauses" looks suspicious :) Also note version value at http://hackage.haskell.org/package/cpphs-1.18.2/src/cpphs.hs, there's a wrong version number as I mentioned in original report, which does not directly affect compilation issue, but does increase confusion ;) There's a new test file at http://hackage.haskell.org/package/cpphs-1.18.2/src/tests/cheplyaka that suggests that a bug in boolean expressions support was fixed recently. To my naked eye, Type/Eq.hs looks correct (and it works with cpp), so I guess this is most likely a regression introduced in recent version of cpphs. I'll try to notice author of cpphs about this issue. Best Regards |
Thanks a bunch! Let me know if the author of cpphs agrees with this assessment, and if so I'll close this issue. |
I just had an offline conversation with Malcolm about this. We both noticed that the problem seems to arise from parentheses, in particular the difference between the following two lines:
Changing the type-eq codebase from the former to the latter seems to resolve the issue. I won't claim to be enough of an expert on CPP to understand the semantics of this, but at least gcc's CPP implementation agrees with Malcolm. |
Also, out of curiosity: why are you using cpphs here at all? If I disable the cpphs preprocessor from the cabal file, everything still compiles. |
Interesting. The reason (IIRC, but I think I do) the parentheses are there is because in an earlier version of Cabal (or maybe it was cabal-install, whichever thing provides it), the
Not on every platform. See bug #1. :) |
Not the OS X issue! I thought we generally agreed to stop going crazy trying to work around a broken CPP implementation and instead gave OS X users a working CPP. |
...a working CPP that's not cpphs? |
(FWIW, I wasn't aware of any of this general goings-on.) |
Here's the comment that informed me of this solution: snoyberg/conduit#124 (comment). conduit was the second package where I got requests to totally redo the way comments were written to work around Maverick's new CPP processor. |
I think in CPP it's common to put parentheses around macro calls because of this: http://gcc.gnu.org/onlinedocs/cpp/Operator-Precedence-Problems.html. In short, macro expansion order might expand I'm not sure if it applies to cpphs. |
@mpietrzak Yes, this is the essence of the earlier Is there a reason why fixing/changing cpphs to accept this syntax would not be a good way forward? (Again, this is not the only package which does it like this.) |
I'd take it up with Malcolm. I've never written my CPP macros that way, and don't really understand its syntax that well. |
@glaebhoerl I think that the dependence on cpphs is worse than you realize: your MIN_VERSION macros probably haven't been working at all since you started using cpphs, since you aren't telling cpphs about your cabal_macros.h file. |
I've done a very simple test to see how/what gets evaluated: I've modified Type/Eq.hs in following ways: First, I've split #if !(...) into separate #define and #if to avoid having So instead of:
I have:
I've done this at 28th and around 50th line. Secondly, I've added following lines after imports:
After those changes Type/Eq.hs compilation no longer ends with "cannot parse" error. Also it seems that macro expands to proper Haskell boolean expression, even if ghc shows warnings ("Defaulting the following constraint(s) to type `Integer'"). I've installed this modified version to default package registry at $HOME/.cabal using I've then switched to separate empty directory (so I don't accidentally compile/use local sources) and created a test program with following contents:
I'm using Homebrew's distribution of Haskell Platform and I believe version of my I've compiled test code with ghc and executed it, and it printed:
I hope I didn't mix anything up, but I guess if I didn't install and compile type-eq properly, then my test program also wouldn't compile. I've double checked and "build-tools" and "ghc-options" are uncommented, as downloaded from Hackage. To triple check I've deleted cpphs and issued mp |
@mpietrzak Thanks! That's cool, I didn't know (Again, I suspect the pain from this apparent-regression will be wider than just this one package, but maybe I'll do it anyways.) |
Doh, I see the problem: I misread the cabal file. For some reason, I thought you were using cpphs as a code formatter. I see that you're passing it in as a replacement for the system CPP. I withdraw my comments. This seems like a straight cpphs bug regarding parentheses. Nonetheless, I'd drop the usage of cpphs here. The workaround is to deal with problems with Mac OS X's CPP, but the accepted solution in the community seems to be to install GCC's CPP. |
@snoyberg I'm also using cpphs-style |
In that case, I think your options are:
I'd recommend going for (1). |
Okay, upon further testing it seems to me like the |
@mpietrzak Could you please check if |
@glaebhoerl I'd recommend moving ahead with a patch that drops the cpphs dependency for now. The current release on Hackage is guaranteed to fail for anyone installing from scratch, and dropping cpphs will most likely work for everyone, the one exception being Mavericks users who haven't installed the CPP fix. |
The safe thing for OS X users is to install haskell platform through homebrew, that always worked with type-eq. Three people had problems and at least two of them used the binary installer and then applied the |
Hello! So at @bergmark's request I did the tiny pull request that became 0.4.1. I don't really know what's going on, but I happen to have a Mavericks system with Platform from the binary installer. So if you want some patch tested on that setup, just mention me. :) |
Thanks @mbrock! My fear is that dropping the cpphs dependency will break a lot of users again, but perhaps there is no short term solution that works for everyone. Here's what I've gathered:
|
Again, my experiments with all of cpphs 1.11, 1.18.1, and 1.18.2 show that If I put this near the beginning of
and try to build the package, I get I'm trying to get confirmation of this from someone else, because it's surprising to me that Cabal's |
I can confirm your results. |
Thanks! Given that the only package whose version needs to be branched on is |
In that case, why not just use GLASGOW_HASKELL? |
It seems e.g. |
I will soon be releasing a new version of cpphs (1.18.3), to fix a bunch of integer arithmetic and precedence issues in the #if conditional evaluator. (And yes, 1.18.2 incorrectly reports itself as 1.18.1). However, the main issue seems to be that ghc does not pass the cabal_macros.h file to the preprocessor, so there is simply no visible definition of MIN_VERSION_base(x,y,z) as far as cpphs can see. |
@malcolmwallace I believe I ruled that possibility out (see also above):
This doesn't trigger, ergo I also tried explicit So my conclusion is that cabal_macros.h is being automatically included, and the problem is around evaluating the |
I pushed a new version that uses |
I successfully built a4676ed on Mavericks with the Platform from the installer and the Clang wrapper script. 💃 |
a4676ed builds on my homebrew installed HP on Mavericks as well. Looking good, thanks! |
With cpphs-1.18.3, I think everything works as expected: $ ../cpphs gabor $ ../cpphs '-DMIN_VERSION_base(x,y,z)=foo' gabor $ ../cpphs '-DMIN_VERSION_base(x,y,z)=1' gabor |
I can confirm a successful install with cpphs-1.18.3 and type-eq 0.4.1. |
Uploaded 0.4.2 to Hackage. @malcolmwallace Great! I'm sticking with the approach that avoids Thanks everyone for the assistance. |
While trying to cabal install type-eq 0.4.1 using cpphs 1.18.2 I get "Cannot parse #if directive" error.
type-eq 0.4 with cpphs 1.18.2 works
type-eq 0.4.1 with cpphs 1.18.1 also works
Note that cpphs 1.18.2 incorrectly reports version 1.18.1 to console when invoked with --version parameter:
I'm not sure if this is type-eq bug or cpphs bug, since I don't know if the offending line is correct cpphs code. Sorry if this should be reported to cpphs instead.
The text was updated successfully, but these errors were encountered: