QuasiQuotation library for programmatic generation of Javascript code. (http://www.haskell.org/haskellwiki/Jmacro)
#2JMacro won't compile with profiling
The following command:
$ stack install jmacro --executable-profiling
yelds:
Language/Javascript/JMacro/Prelude.hs:19:13: cannot find normal object file ‘.stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/jmacro/jmacro-tmp/Language/Javascript/JMacro/Types.dyn_o’
just ran: cabal configure --enable-executable-profiling cabal build
and it worked fine.
I suspect this is an issue with stack, since the executable relies on the library and in particular the TH of the library.
That said, in these circumstances, sometimes adding "other-extensions: TemplateHaskell" to the cabal file itself seems to fix things. Could you try this and let me know if it helps the situation. If so, I'll add it upstream as well.
Hi,
It is not a stack issue. We are compiling our whole system with both stack and cabal toolchain (because I only recently added stack support into our toolchain and until recently we considered it experimental) and it failes both with cabal and with stack.
To be more precise I can confirm that it fails in the following setups: - ghc 7.10, cabal 1.22, osx x64 - ghc 7.10, cabal 1.22, linux x64 - ghc 7.10, stack, osx x64 - ghc 7.10, stack, linux x64
I could not find any other workaround than to only put jmacro on the few leaf projects that are really using it and for those projects to turn off profiling.
Just wanted to chime in and say that I'm experiencing this too and in almost the same circumstances. I don't really have the ability to drop jmacro though because it is an indirect dependency of a few projects I depend on, so I am unable to produce a profiling binary of my project. The snap project has a seemingly related workaround documented (http://snapframework.com/faq#why-do-i-get-a-cannot-find-normal-object-file-error-when-building-snap) but I've yet to have any success with it. Adding "other-extensions: TemplateHaskell" to jmacro didn't seem to help.
Sorry for the slow response here. I think the new version 0.6.14 should fix this (and that it had to do something with how the bundled executable was setup). At least I successfully tested building a few times.
- status set to closed
