| 20 Feb 2025 |
John Ericson | IMO a <....> is undeused | 23:06:07 |
emily | yes, I just forget whether "system headers" can use non-system includes to include other system headers without issues or not | 23:06:22 |
John Ericson | from the perspective of owns own project, it is weird, but headers are not for that perspective! | 23:06:28 |
John Ericson | emily: Robert Hensing (roberth) OK it should work now | 23:15:59 |
roberth | meson is compiling, clangd is happy 🎉 | 23:30:37 |
| 21 Feb 2025 |
Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org (don't quote me on this though) I don’t think that’s how it works. ”…” and <…> only affect default search path preferences https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html. I our case this distinction does not make a difference.
To disable warnings you have to include directories via -isystem and not via -I.
For reference, Cmake does that with SYSTEM flag in target_include_directories:
https://cmake.org/cmake/help/latest/command/target_include_directories.html
Some discussions about meson’s handling of system includes: https://github.com/mesonbuild/meson/issues/963
https://github.com/mesonbuild/meson/pull/5953
Barring some unforeseen differences around search path preferences/order shenanigans it really doesn’t matter semantically.
I think in general the de-facto rule/convention is to refer to one’s own headers with quotes to highlight to the reader that it’s part of the same project and not an external library. | 06:00:51 |
| alexandi joined the room. | 06:52:57 |
| jasi 🏳️⚧️ joined the room. | 16:37:46 |
| 22 Feb 2025 |
| @selachimorpha:matrix.org changed their display name from selachimorpha to cogitoblood. | 01:36:18 |
| @selachimorpha:matrix.org left the room. | 01:39:48 |
| 24 Feb 2025 |
| ubalot left the room. | 07:40:55 |
| Zm94ZGV2 changed their profile picture. | 13:15:52 |
emily | is it known/expected that pkgsStatic.nixVersions.nix_2_26, pkgsCross.*.nixVersions.nix_2_26, etc., all cause a throw? this seems like another regression of importing the flake packaging into Nixpkgs | 17:44:12 |
John Ericson | CC Robert Hensing (roberth) ^ | 18:23:07 |
John Ericson | I don't think so? | 18:23:10 |
John Ericson | thanks for pointing out | 18:23:16 |
emily | another question:
# boost is a public dependency, but not a pkg-config dependency unfortunately, so we
# put in `deps_other`.
why? Boost has .pc files (in Nixpkgs at least), and this breaks e.g. Rust pkg_config parsing the dependencies out of the .pc files
| 18:32:40 |
emily | * another question:
# boost is a public dependency, but not a pkg-config dependency unfortunately, so we
# put in `deps_other`.
why? Boost has .pc files (in Nixpkgs at least), and this breaks e.g. Rust pkg_config parsing the dependencies out of the Nix .pc files
| 18:32:44 |
emily | (fwiw, nixVersions.latest is also not 2.26, although I had been assuming that was intentional while the packaging bakes) | 18:34:59 |
John Ericson | @emilazy:matrix.org: oh awesome! | 18:35:35 |
John Ericson | Maybe the PC file was new? | 18:35:50 |
emily | Nixpkgs bumped its Boost a couple times recently, so that may have been a factor | 18:36:05 |
emily | (in particular, it breaks it for pkgsStatic, because the resulting .pc file has e.g. Libs: -L${libdir} -lnixstore -pthread /nix/store/2hbky50x3hzky0drn4ay87xj77frq27c-boost-static-x86_64-unknown-linux-musl-1.81.0/lib/libboost_container.a and the pkg_config crate just discards the absolute path, seemingly) | 18:36:34 |
emily | (that's probably a ~bug-ish on the Rust end, but I think parsing useful semantic information out of .pc files is really hard in general, so it would work better if it's -lboost_container with a Requires/Requires.private) | 18:37:00 |
John Ericson | Also, if we could make progress on breaking up boost then there are some hacks we can remove | 18:37:07 |
emily | (which I think Meson would arrange automatically if Boost was consumed via .pc) | 18:37:07 |
John Ericson | I am very pro pc-file-or-best, don't mind there being a Rust bug ;) | 18:37:24 |
John Ericson | * I am very pro pc-file-or-best, don't mind there being a Rust bug :) | 18:37:26 |
emily | I'm happy to review Nixpkgs changes to break up Boost. it should probably just be a bunch of boost-* packages in pkgs/by-name, with a buildBoostComponent builder for each, and a shared src. | 18:37:48 |
emily | I believe the libraries can basically be built independently and other distros do this. | 18:38:02 |