Newest at the top
| 2024-11-08 23:26:54 +0100 | <jle`> | hm. yeah, i was thinking, Cmake has its CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES option but that's because it actually does handle locating system libs |
| 2024-11-08 23:26:30 +0100 | <geekosaur> | (in particular, C++ includes on Debian/Ubuntu will depend on which version of the C++ includes/libraries are active) |
| 2024-11-08 23:26:23 +0100 | <darkling> | Linking, I'm happy to hand off. ASM-level optimisation from some abstract machine-code representation, likewise. But I wouldn't describe either of those as "C compiler". |
| 2024-11-08 23:26:05 +0100 | <monochrom> | It was a simpler time. Then again, I could not bring 100 CDs worth of music with me back then, now any smartphone can do it. |
| 2024-11-08 23:26:03 +0100 | <geekosaur> | and includes, which is your problem |
| 2024-11-08 23:25:57 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-11-08 23:25:52 +0100 | <jle`> | geekosaur: ah that makes sense. it lets gcc/g++ handle where to find implicit system libraries |
| 2024-11-08 23:25:35 +0100 | <jle`> | ah yeah i am specifically talking about FFI |
| 2024-11-08 23:25:10 +0100 | <geekosaur> | and linking is done via the C compiler so ghc doesn;t have to know the location of system libraries or how exactly you link the C RTS into a program |
| 2024-11-08 23:24:58 +0100 | <jle`> | monochrom: thanks! appreciate it, it was fun to write :) |
| 2024-11-08 23:24:51 +0100 | <monochrom> | me too |
| 2024-11-08 23:24:44 +0100 | <darkling> | Glad to hear it. (I'm old enough to remember cfront for C++). :) |
| 2024-11-08 23:24:35 +0100 | <geekosaur> | FFI export stubs and C stubs for CApiFFI go through the C compiler, though |
| 2024-11-08 23:24:16 +0100 | <monochrom> | GHC no longer goes through C. It goes to asm or llvm. |
| 2024-11-08 23:24:04 +0100 | <geekosaur> | ghc hasn't transpiled to C since 7.2 |
| 2024-11-08 23:23:48 +0100 | <darkling> | Does ghc actually transpile to C, or does it just use some part of the back-end of a C compiler? (code generation and ASM-level optimisations, say?) |
| 2024-11-08 23:23:21 +0100 | <monochrom> | Oh hey jle` I read your free applicative article (found via HWN) and the related free alternative article. Very interesting! |
| 2024-11-08 23:22:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-11-08 23:22:09 +0100 | <geekosaur> | ghc in particular hands as much as possible off to the C compiler to figure out |
| 2024-11-08 23:21:27 +0100 | <geekosaur> | (both would have to know way too much about the machine they're building on to generate them themselves) |
| 2024-11-08 23:20:04 +0100 | <geekosaur> | unless cross-compiling, which ghc is poor at and cabal more or less doesn't support as yet |
| 2024-11-08 23:19:56 +0100 | Natch | (~natch@c-92-34-7-158.bbcust.telenor.se) Natch |
| 2024-11-08 23:19:28 +0100 | <geekosaur> | neither, `-isystem` should usually not be touched and I'm pretty sure neither cabal nor ghc does |
| 2024-11-08 23:18:42 +0100 | <jle`> | i wonder if this is a ghc thing or a cabal thing ... |
| 2024-11-08 23:18:37 +0100 | <jle`> | it builds fine but i'm triyng to use bear to generate compile_commands.json |
| 2024-11-08 23:18:20 +0100 | <jle`> | is there any way to get cabal to be explicit about its -isystem includes when building c? it doesn't seem to include the c standard headers or c++ ones either when doing c++ |
| 2024-11-08 23:17:47 +0100 | michalz | (~michalz@185.246.207.217) (Remote host closed the connection) |
| 2024-11-08 23:17:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 23:17:21 +0100 | sprotte24 | (~sprotte24@p200300d16f0bb9000907ce5a9cbe4fad.dip0.t-ipconnect.de) |
| 2024-11-08 23:13:43 +0100 | Everything | (~Everythin@178-133-144-57.mobile.vf-ua.net) Everything |
| 2024-11-08 23:06:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-11-08 23:02:32 +0100 | user363627 | (~user@user/user363627) (Ping timeout: 265 seconds) |
| 2024-11-08 23:01:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 22:59:14 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-08 22:59:02 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-08 22:50:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-11-08 22:44:38 +0100 | benjaminl | olivial |
| 2024-11-08 22:43:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 22:37:10 +0100 | yvan-sraka | (uid419690@id-419690.lymington.irccloud.com) yvan-sraka |
| 2024-11-08 22:34:21 +0100 | visilii | (~visilii@85.172.77.90) |
| 2024-11-08 22:32:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-08 22:28:57 +0100 | famubu | (~famubu@14.139.174.50) (Ping timeout: 246 seconds) |
| 2024-11-08 22:28:29 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 255 seconds) |
| 2024-11-08 22:27:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 22:26:46 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-08 22:21:50 +0100 | <geekosaur> | or the mechanism that uses, which is via TH |
| 2024-11-08 22:20:39 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-11-08 22:17:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-11-08 22:16:38 +0100 | <SrPx> | ty |
| 2024-11-08 22:16:31 +0100 | <tomsmeding> | SrPx: https://hackage.haskell.org/package/file-embed |