Yes I am. I put allow newer in both because stack complained about dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error. -- Brandon Martin On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:

Are you using the same dependency set (including GHC version) that you used on Linux too?

Why did you enable allow-newer?

Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin :

...

I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:

Not in scope: type constructor or class ‘HsType’

Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c

HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.

Thanks

-- Brandon Martin

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Hmm... maybe I am missing a package in FreeBSD then? Is that the possible suggestion? -- Brandon Martin On Fri, Jan 31, 2020, at 5:12 PM, Simon Jakobi wrote:

I think the error suggests that the C pre-processor doesn't work as expected. Look at the source around the error locations:

https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f6...

"HsType" is a variable name used in the CPP definition.

Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin :

...

Yes I am. I put allow newer in both because stack complained about dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error.

-- Brandon Martin

On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:

...

Are you using the same dependency set (including GHC version) that you used on Linux too?

Why did you enable allow-newer?

Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin :

...

I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:

Not in scope: type constructor or class ‘HsType’

Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c

HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.

Thanks

-- Brandon Martin

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Sat, Feb 1, 2020 at 5:31 AM Simon Jakobi via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

Maybe. Though it seems to me that the pre-processor isn't missing, but it's doing the wrong thing…

I'd suggest to open an issue at https://gitlab.haskell.org/ghc/ghc/issues – there should be people who can tell more exactly what's going wrong here.

FreeBSD uses Clang as C/C++ compiler. While its preprocessor should be 100% compatible with GCC's one, it might explain why the problem appears.

Am Sa., 1. Feb. 2020 um 02:16 Uhr schrieb Brandon Martin :

...

Hmm... maybe I am missing a package in FreeBSD then? Is that the

possible suggestion?

...

-- Brandon Martin

On Fri, Jan 31, 2020, at 5:12 PM, Simon Jakobi wrote:

...

I think the error suggests that the C pre-processor doesn't work as expected. Look at the source around the error locations:

https://github.com/rblaze/haskell-dbus/blob/43b1382ce93f08272fd6fda253d977f6...

...

...

"HsType" is a variable name used in the CPP definition.

Am Sa., 1. Feb. 2020 um 01:58 Uhr schrieb Brandon Martin :

...

Yes I am. I put allow newer in both because stack complained about

dependencies, and suggested it. I just put it in as a quick test to see if I could build it. Cabal didn't complain about dependencies, but got the same error.

...

...

-- Brandon Martin

On Fri, Jan 31, 2020, at 4:55 PM, Simon Jakobi wrote:

...

Are you using the same dependency set (including GHC version) that

you

...

...

used on Linux too?

Why did you enable allow-newer?

Am Sa., 1. Feb. 2020 um 01:30 Uhr schrieb Brandon Martin :

...

I am trying to build haskell-dbus on FreeBSD 12.1. I have tried

with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:

...

Not in scope: type constructor or class ‘HsType’

Full error:

https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c

...

HsType is part of ghc unless I am missing something. I am new to

using FreeBSD as I usually use Linux. This package builds fine for me on Linux.

...

Thanks

-- Brandon Martin

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Sat, Feb 01, 2020 at 12:26:32PM +0400, Gleb Popov wrote:

Yep, the problem is with Clang's preprocessor. Running it manually results in a bunch of

warning: missing terminating ' character [-Winvalid-pp-token]

messages.

I don't think it is just clang, the macros are not not valid C-preprocessor input. $ for cpp in gcc{7,8,8} clang{37,39,60,70}; do printf "--- CPP: %s\n" "$cpp" printf "#define foo a' = b\nfoo\n" | $cpp -Werror -E - 2>&1 printf "EXIT: $?\n" done | egrep -v '^# [0-9]|^$' --- CPP: gcc7 <stdin>:1:14: error: missing terminating ' character [-Werror] a' = b cc1: all warnings being treated as errors EXIT: 1 --- CPP: gcc8 <stdin>:1:14: error: missing terminating ' character [-Werror] a' = b cc1: all warnings being treated as errors EXIT: 1 --- CPP: gcc8 <stdin>:1:14: error: missing terminating ' character [-Werror] a' = b cc1: all warnings being treated as errors EXIT: 1 --- CPP: clang37 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 --- CPP: clang39 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 --- CPP: clang60 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 --- CPP: clang70 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1

This is the case for IsValue instance, which contain typeOf' method.

Not sure if this should be reported to the package developer, GHC devs or Clang devs.

The package developer. Neither GHC nor Clang are at-fault for invalid CPP macro syntax. -- Viktor.

On Sat, Feb 01, 2020 at 11:36:19AM +0100, Merijn Verstraaten wrote:

...

On 1 Feb 2020, at 10:01, Viktor Dukhovni wrote:

The package developer. Neither GHC nor Clang are at-fault for invalid CPP macro syntax.

This isn't the package developers fault. Standard Haskell just cannot be properly preprocessed by an ISO C preprocessor. As the definition of valid tokens just aren't compatible.

Well, my take was the package developer using "CPP" is expected to produce CPP-compatible input. But if Haskell is expected to provide a more liberal dialect of CPP, then indeed perhaps the issue is with the Haskell build using Clang's CPP.

GHC's use of the CPP has long (maybe since forever?) been incompatible with CPP as standardised in the ISO C spec, and its relies on the -traditional flag to make GCC use it's pre-ISO C implementations. This flag isn't necessarily portable across C compilers and I recall this breaking things in the past.

Indeed the -traditional flag shows the difference, only GCC's "cpp" tolerates the C-incompatible tokens, Clang does not. $ for cpp in gcc{7,8,9} clang{37,39,60,70}; do printf "--- CPP: %s\n" "$cpp"; printf "#define foo a' = b\nfoo\n" | $cpp -traditional -Werror -E - 2>&1; printf "EXIT: $?\n"; done | egrep -v '^# [0-9]|^$' --- CPP: gcc7 a' = b EXIT: 0 --- CPP: gcc8 a' = b EXIT: 0 --- CPP: gcc9 a' = b EXIT: 0 --- CPP: clang37 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 --- CPP: clang39 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 --- CPP: clang60 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 --- CPP: clang70 <stdin>:1:14: error: missing terminating ' character [-Werror,-Winvalid-pp-token] #define foo a' = b ^ a' = b 1 error generated. EXIT: 1 My own build of GHC for FreeBSD has settings: [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "gcc"), ("C compiler flags", ""), ("C compiler link flags", " -fuse-ld=lld"), ("C compiler supports -no-pie", "YES"), ("Haskell CPP command","gcc"), ("Haskell CPP flags","-E -undef -traditional"), ... ] It seems that the ports system elects clang, leading to the reported issue. I see that FreeBSD ports also include: hs-cpphs-1.20.8_7 Liberalised re-implementation of cpp, the C pre-processor Which means that either hs-cpphs needs to be a pre-requisite (built by the boostrap GHC compiler?), a co-requisite (assuming GHC itself does not break with clang's CPP), or the configuration needs be tweaked to use "gcc" as the Haskell CPP preprocessor, even when clang is the compiler. -- Viktor.

I've been complaining about that for years. Every so often there's discussion of a non-GPLed alternative preprocessor, but the questions apparently become fairly hairy quickly, so the current mess is just accepted. :( On Sat, Feb 1, 2020 at 10:19 AM Ben Franksen wrote:

Am 01.02.20 um 11:36 schrieb Merijn Verstraaten:

...

...

On 1 Feb 2020, at 10:01, Viktor Dukhovni wrote:

The package developer. Neither GHC nor Clang are at-fault for invalid CPP macro syntax.

This isn't the package developers fault. Standard Haskell just cannot be properly preprocessed by an ISO C preprocessor. As the definition of valid tokens just aren't compatible.

GHC's use of the CPP has long (maybe since forever?) been incompatible with CPP as standardised in the ISO C spec, and its relies on the -traditional flag to make GCC use it's pre-ISO C implementations. This flag isn't necessarily portable across C compilers and I recall this breaking things in the past.

This situation strikes me as being precarious. It means we rely on the gcc developers to retain the -traditional flag (with its current semantics). My personal experience makes me think that such reliance is ill-advised: breaking compatibility with anything other than C or C++ source code is not regarded as a problem and bug reports to that effect are rejected as invalid.

Cheers Ben _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Comingling of c and Haskell code of incompatible licenses is way harder to do by accident than Haskell and Haskell. Every arms length subsystem volunteers have to maintain is more complexity to juggle. Solution : let someone get angry enough that they volunteer to fix it and encourage them. If it’s frustrating, help fix it. On Sat, Feb 1, 2020 at 5:59 PM Ben Franksen wrote:

Am 01.02.20 um 16:30 schrieb Brandon Allbery:

...

I've been complaining about that for years. Every so often there's discussion of a non-GPLed alternative preprocessor, but the questions apparently become fairly hairy quickly, so the current mess is just accepted. :(

I find it strangely inconsistent that using cpphs is found to be problematic because of its GPL license, while using the equally GPL licensed gcc C preprocessor is not. Can anyone shed light on this? _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

With stack: ➜ haskell-dbus git:(master) ✗ stack exec ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.6.5 System ghc and cabal: ➜ haskell-dbus git:(master) ✗ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.5 Same versions on my Linux machine as well. -- Brandon Martin On Fri, Jan 31, 2020, at 5:03 PM, Andrey Sverdlichenko wrote:

What's your ghc version? It looks like you are trying to build a new package with the older compiler.

On Fri, Jan 31, 2020 at 7:30 PM Brandon Martin wrote:

...

I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error:

Not in scope: type constructor or class ‘HsType’

Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c

HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux.

Thanks

-- Brandon Martin

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.