Re: Building GHC head with clang on Mavericks
2014/1/2 Carter Schonwald carter.schonw...@gmail.com: it looks like their work around is using ## rather than /**/ Well, actually lens is bypassing the problem by using cpphs, not the C preprocessor. :-P OpenGLRaw is part of the Haskell Platform, and cpphs is not, so I can't simply depend on it. (Licensing issues IIRC?) Don't do that is not an option, either, at least not until the binding is auto-generated. If I see this correctly, I really have to do some preprocessor magic (slightly simplified output): - svenpanne@svenpanne:~$ cat preprocess.hs #define FOO(x) bla/**/x x #define BAR(x) bla##x #x FOO(baz) BAR(boo) svenpanne@svenpanne:~$ gcc -traditional -E -x c preprocess.hs blabaz baz bla##boo #boo svenpanne@svenpanne:~$ gcc -E -x c preprocess.hs bla baz x blaboo boo svenpanne@svenpanne:~$ clang -traditional -E -x c preprocess.hs bla baz x bla##boo #boo svenpanne@svenpanne:~$ clang -E -x c preprocess.hs bla baz x blaboo boo - If -traditional is not used, things are simple and consistent, and we can simply use ## and #. Alas, -traditional *is* used, so we can't use ## and # with gcc an we are out of luck with clang. This really sucks, and I consider the clang -traditional behavior a bug: How can you do concatenation/stringification with clang -traditional? One can detect clang via defined(__clang__) and the absence of -traditional via defined(__STDC__), but this doesn't really help here. Any suggestions? I am testing with a local clang 3.4 version (trunk 193323), but I am not sure if this matters. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Although it is not really GHC-related, this thread is sufficiently close to the problem described in https://github.com/haskell-opengl/OpenGLRaw/issues/18: AFAICT, Mac OS X 10.9's clang doesn't really honor -traditional, so what can I do to make things work with recent Macs without breaking all other platforms? I guess the right #if in https://github.com/haskell-opengl/OpenGLRaw/blob/master/include/HsOpenGLRaw.h will do the trick, but I don't have access to a Mac. Hints are highly appreciated, the whole current Mac situation is a bit of a mystery to me... Cheers, S. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
2014/1/2 Carter Schonwald carter.schonw...@gmail.com: sven,http://www.haskell.org/platform/mac.html has a wrapper script that makes clang play nice with CPP, though a simpler alternative one can be found on manuel's page [...] I've seen the wrappers before, but do they really solve the problem for OpenGLRaw (concatenation via /**/ and replacement in strings)? As I said, I don't have access to a Mac, but the mangled options don't look like if they have anything to do with that. Can somebody confirm that? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
oh right, that is a problem with clang no matter what. lens hit this issue, https://github.com/ekmett/lens/issues/357 I think the solution is don't do that if you want to support clang being the C compiler GHC uses, though you'll have to look at the diffs on that ticket closely to see how they addressed it On Thu, Jan 2, 2014 at 4:31 PM, Sven Panne svenpa...@gmail.com wrote: 2014/1/2 Carter Schonwald carter.schonw...@gmail.com: sven,http://www.haskell.org/platform/mac.html has a wrapper script that makes clang play nice with CPP, though a simpler alternative one can be found on manuel's page [...] I've seen the wrappers before, but do they really solve the problem for OpenGLRaw (concatenation via /**/ and replacement in strings)? As I said, I don't have access to a Mac, but the mangled options don't look like if they have anything to do with that. Can somebody confirm that? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
it looks like their work around is using ## rather than /**/ On Thu, Jan 2, 2014 at 4:51 PM, Carter Schonwald carter.schonw...@gmail.com wrote: oh right, that is a problem with clang no matter what. lens hit this issue, https://github.com/ekmett/lens/issues/357 I think the solution is don't do that if you want to support clang being the C compiler GHC uses, though you'll have to look at the diffs on that ticket closely to see how they addressed it On Thu, Jan 2, 2014 at 4:31 PM, Sven Panne svenpa...@gmail.com wrote: 2014/1/2 Carter Schonwald carter.schonw...@gmail.com: sven,http://www.haskell.org/platform/mac.html has a wrapper script that makes clang play nice with CPP, though a simpler alternative one can be found on manuel's page [...] I've seen the wrappers before, but do they really solve the problem for OpenGLRaw (concatenation via /**/ and replacement in strings)? As I said, I don't have access to a Mac, but the mangled options don't look like if they have anything to do with that. Can somebody confirm that? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hi Simon, I think he has forgotten, yes. But yeah do send the pull requests anyway, my last set got merged in. Done: https://github.com/simonmar/happy/pull/13 https://github.com/simonmar/alex/pull/38 I've merged these and made new releases of Happy (1.19.2) and Alex (3.1.3). I verified that this happy and alex can build GHC head on Mavericks. Thank you! --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
On 21/11/13 06:54, Kazu Yamamoto (山本和彦) wrote: I think he has forgotten, yes. But yeah do send the pull requests anyway, my last set got merged in. Done: https://github.com/simonmar/happy/pull/13 https://github.com/simonmar/alex/pull/38 I've merged these and made new releases of Happy (1.19.2) and Alex (3.1.3). Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hi, Kazu, can you put create pull requests for happy and alex with your required changes? I have one concern. The version of alex on Hackage is 3.1.2. But that of github is 3.1.1: https://github.com/simonmar/alex/blob/master/alex.cabal # This inconsistency exists in happy, too. Did SimonM forget to push his local changes? Should I send pull requests on github, anyway? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
I think he has forgotten, yes. But yeah do send the pull requests anyway, my last set got merged in. Done: https://github.com/simonmar/happy/pull/13 https://github.com/simonmar/alex/pull/38 --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
So did you find a bug in the current design of the clang-wrapper hack? If
so it'd be better to get it fixed there rather than in the Alex/happy setup
HS files.
On Tuesday, November 19, 2013, Kazu Yamamoto wrote:
Hi Carter,
SimonM, please read this message.
I will answer Carter's question and show a solution of my problem.
Kazu. This is exactly the problem I linked to. Could you try the
proposed
patches to test if they allow builds to succeed with a wrapped clang on
your machine?
I installed nkpart's alex and happy with GHC/clang-wrapper. With this
alex and happy, I can build GHC head with GHC/GCC42. But I cannot
build GHC head with GHC/clang-wrapper.
Moreover, I can install happy and alex with GHC/clang-wrapper without
nkpart's patches.
I think that your problem is how to build alex and happy with
GHC/clang-wrapper. But my problem is how to compile HS files created
by alex and happy with GHC/clang-wrapper.
After deep investigation, I found the source of my problem. Consider
the following file created by CPP of clang or GCC:
# 1 built-inxxx 1
# 1 templates/GenericTemplatexxx.hs 2
{-# FOO
#-}
% clang -E -undef -x assembler-with-cpp this_file
generates:
# 1 test
# 1 built-in 1
# 1 test 2
# 1 built-inxxx 1
# 1 templates/GenericTemplatexxx.hs 2
{-# FOO
#-}
So, the line started with # cannot be treated by GHC. This is the
problem.
% clang -E -undef -x c this_file
generates:
# 1 test
# 1 built-in 1
# 1 built-in 3
# 1 command line 1
# 1 built-in 2
# 1 test 2
# 1 built-inxxx 1
# 1 templates/GenericTemplatexxx.hs 2
{-# FOO
And an error occurs because of #-}.
So, replacing -x c with -x assembler-with-cpp in a wrapper is a
MUST. And HS files generated by alex and happy should not include
lines started with # .
My solution so far is adding -optP-P to alex and happy to not
generate line markers. An example patch to alex is attached.
I can build GHC head with GHC/clang-wrapper and with alex and happy
with this hack.
--Kazu
diff --git a/Setup.lhs b/Setup.lhs
index 302a3f0..6ab62d5 100644
--- a/Setup.lhs
+++ b/Setup.lhs
@@ -44,7 +44,7 @@ myPostBuild _ flags _ lbi = do
runProgram p = rawSystemProgramConf verbosity p (withPrograms lbi)
cpp_template src dst opts = do
let tmp = dst ++ .tmp
-runProgram ghcProgram ([-o, tmp, -E, -cpp, templates /
src] ++ opts)
+runProgram ghcProgram ([-o, tmp, -E, -cpp, -optP-P,
templates / src] ++ opts)
writeFile dst . unlines . map mungeLinePragma . lines =
readFile tmp
removeFile tmp
___
ghc-devs mailing list
ghc-devs@haskell.org javascript:;
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
so what are you proposing? Are you agreeing that those patches work with
clang wrapper, but also remarking that its unfortunate that such a hack is
needed?
On Tue, Nov 19, 2013 at 4:52 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
So did you find a bug in the current design of the clang-wrapper hack?
No. What I found is that the current design of the clang-wrapper hack
is appropriate.
-x assembler-with-cpp is necessary to rescue
{-# RULE whatever
#-}
---
If so it'd be better to get it fixed there rather than in the
Alex/happy setup HS files.
If we can do this, it's very good. But this is not good enough.
happy/alex hack are also necessary to not generate
# 1 built-inxxx 1
# 1 templates/GenericTemplatexxx.hs 2
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hi, so what are you proposing? I'm not proposing anything. I just want to share information so that we can find a good solution. Are you agreeing that those patches work with clang wrapper, but also remarking that its unfortunate that such a hack is needed? As I said, nkpart's patches are not necessary in my environment. But they do not side-effect, so it is fine with me to apply these patches. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Was there an issue if you used a wrapped clang and those patches or not? I'm really confused. Even with GHC/clang-wrapper and alex/happy with Nick's patches, I cannot build GHC head. (I'm not using GCC 42 at all in this case.) AlexTemplate (pre-processed by clang) has linemarkers like this: # 1 built-in So, Lexer.hs generated from Lexer.x by alex also includes this one. Lexer.hs is CPP language extension. So, it is pre-processed again by clang. Since clang-wrapper specifies -x assembler-with-cpp, generated Lexcer.hscpp contains: # 1 built-in GHC cannot handle this, so build fails. My hack lets alex and happy not to produce linemarkers at all. Is this explanation clear to you? P.S. If we modify clang-wrapper to not convert -x c to -x assembler-with-cpp, some other files which contains #-} cannot be compiled. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Ok. Got it. So some more patches were needed. Pardon the asking, was somehow getting confused earlier. On Tuesday, November 19, 2013, Kazu Yamamoto wrote: Was there an issue if you used a wrapped clang and those patches or not? I'm really confused. Even with GHC/clang-wrapper and alex/happy with Nick's patches, I cannot build GHC head. (I'm not using GCC 42 at all in this case.) AlexTemplate (pre-processed by clang) has linemarkers like this: # 1 built-in So, Lexer.hs generated from Lexer.x by alex also includes this one. Lexer.hs is CPP language extension. So, it is pre-processed again by clang. Since clang-wrapper specifies -x assembler-with-cpp, generated Lexcer.hscpp contains: # 1 built-in GHC cannot handle this, so build fails. My hack lets alex and happy not to produce linemarkers at all. Is this explanation clear to you? P.S. If we modify clang-wrapper to not convert -x c to -x assembler-with-cpp, some other files which contains #-} cannot be compiled. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hi Carter, Nick Partridge hit this recently and he's got PR's pending for Happy and Alex https://github.com/simonmar/alex/pull/37 and https://github.com/simonmar/happy/pull/12 I'm not using GCC. (In my previous message, I made a typo. GCC should be read as clang). So, I think that this is a different problem. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hi,
Adding the -v option, GHC displays:
*** Checking old interface for main:Lexer:
*** Parser:
*** Renamer/typechecker:
built-in:2:2: Not in scope: `#'
-keep-tmp-files keeps generated .hscpp file. The beginning of the
generated .hscpp is:
# 1 utils/genprimopcode/dist/build/Lexer.hs
# 1 built-in 1
# 1 utils/genprimopcode/dist/build/Lexer.hs 2
{-# LANGUAGE CPP,MagicHash #-}
{-# LINE 2 utils/genprimopcode/./Lexer.x #-}
built-in:2:2: Not in scope: `#' in my previous message indicates
this line 2.
I don't know why Renamer/typechecker cannot handle this .hsccp file.
--Kazu
Hi,
As I wrote in the following blog article, I could build GHC head on
Mavericks 20 days ago.
http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
But I cannot build it recently:
/usr/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db
libraries/bootstrapping.conf -i -iutils/genprimopcode/.
-iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen
-Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen
-package array -no-user-package-db -rtsopts -odir
utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir
utils/genprimopcode/dist/build -c utils/genprimopcode/dist/build/Lexer.hs
-o utils/genprimopcode/dist/build/Lexer.o
built-in:2:2: Not in scope: `#'
make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
make[1]: *** Waiting for unfinished jobs
shift/reduce conflicts: 46
reduce/reduce conflicts: 1
make: *** [all] Error 2
I seems to me that linemarkers generated by GCC(CPP) is not correctly
handled when alex is used. Note I can build GHC head on FreeBSD and
Linux.
I'm using clang with clang-xcode5-wrapper.hs.
Any suggestions?
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hi,
I can finally build GHC head on Mavericks. I gave up on clang and
installed GHC 4.8 with MacPorts.
Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I
can build GHC head.
This step is a MUST. If alex and happy are complied GHC
7.6.3/clang-wrapper, I cannot build GHC head with GHC 7.6.3/GHC 4.8.
--Kazu
Hi,
Adding the -v option, GHC displays:
*** Checking old interface for main:Lexer:
*** Parser:
*** Renamer/typechecker:
built-in:2:2: Not in scope: `#'
-keep-tmp-files keeps generated .hscpp file. The beginning of the
generated .hscpp is:
# 1 utils/genprimopcode/dist/build/Lexer.hs
# 1 built-in 1
# 1 utils/genprimopcode/dist/build/Lexer.hs 2
{-# LANGUAGE CPP,MagicHash #-}
{-# LINE 2 utils/genprimopcode/./Lexer.x #-}
built-in:2:2: Not in scope: `#' in my previous message indicates
this line 2.
I don't know why Renamer/typechecker cannot handle this .hsccp file.
--Kazu
Hi,
As I wrote in the following blog article, I could build GHC head on
Mavericks 20 days ago.
http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
But I cannot build it recently:
/usr/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db
libraries/bootstrapping.conf -i -iutils/genprimopcode/.
-iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen
-Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen
-package array -no-user-package-db -rtsopts -odir
utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build
-stubdir utils/genprimopcode/dist/build -c
utils/genprimopcode/dist/build/Lexer.hs -o
utils/genprimopcode/dist/build/Lexer.o
built-in:2:2: Not in scope: `#'
make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1
make[1]: *** Waiting for unfinished jobs
shift/reduce conflicts: 46
reduce/reduce conflicts: 1
make: *** [all] Error 2
I seems to me that linemarkers generated by GCC(CPP) is not correctly
handled when alex is used. Note I can build GHC head on FreeBSD and
Linux.
I'm using clang with clang-xcode5-wrapper.hs.
Any suggestions?
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
Hey Kazu, Nick Partridge hit this recently and he's got PR's pending for Happy and Alex https://github.com/simonmar/alex/pull/37 and https://github.com/simonmar/happy/pull/12 On Mon, Nov 18, 2013 at 1:13 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Hi, As I wrote in the following blog article, I could build GHC head on Mavericks 20 days ago. http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924 But I cannot build it recently: /usr/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o built-in:2:2: Not in scope: `#' make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1 make[1]: *** Waiting for unfinished jobs shift/reduce conflicts: 46 reduce/reduce conflicts: 1 make: *** [all] Error 2 I seems to me that linemarkers generated by GCC(CPP) is not correctly handled when alex is used. Note I can build GHC head on FreeBSD and Linux. I'm using clang with clang-xcode5-wrapper.hs. Any suggestions? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
