lix-project/lix

Fork 55

rename our libraries: libnixexpr -> liblixexpr, etc #279

New issue

Closed

opened 2024-05-07 22:04:17 +00:00 by qyriad · 2 comments

qyriad commented

2024-05-07 22:04:17 +00:00

Owner

Therefore, let's change our pkg-config and library names from libnix{expr,store,cmd,main,util,fetchers} to liblix{expr,store,cmd,main,util,fetchers}

cc @jade

For runtime purposes, we are CppNix 2.18 (compatible; like Gecko), but for build-time purposes, we are Lix, and anything trying to link against us should explicitly detect and support Lix, as there is no way we are going to have perfect header and symbol compatibility with CppNix 2.18 (and the C++ API has never been stable anyway). Therefore, let's change our pkg-config and library names from libnix{expr,store,cmd,main,util,fetchers} to liblix{expr,store,cmd,main,util,fetchers} cc @jade

👍 1 🎉 1

qyriad added this to the v2.90 milestone

2024-05-07 22:04:17 +00:00

qyriad added the

Area/build-packaging

label

2024-05-07 22:04:17 +00:00

qyriad self-assigned this

2024-05-07 22:04:17 +00:00

qyriad added the

Downstream Dependents

label

2024-05-07 22:05:43 +00:00

arcuru referenced this issue

2024-05-08 06:13:28 +00:00

nix-du fails to build #275

bbjubjub2494 referenced this issue

2024-05-08 07:54:56 +00:00

nix-du fails to build #275

jade added this to the Release engineering (releng) project

2024-05-09 06:42:11 +00:00

jade added the

release-blocker

label

2024-05-09 06:42:21 +00:00

jade commented

2024-05-09 06:43:14 +00:00

Owner

imo this needs to be complete for release to prevent anyone writing bad lix detection code that will later need to be dealt with.

👍 1

qyriad was unassigned by jade

2024-05-16 22:59:11 +00:00

jade self-assigned this

2024-05-16 22:59:14 +00:00

jade referenced this issue from lix-project/nix-eval-jobs

2024-05-17 00:05:39 +00:00

nixexpr -> lixexpr #5

jade commented

2024-05-20 19:41:33 +00:00

Owner

OK so there is the approach suggested in the CL, which is just nix -> lix externally. But we could actually also squish a secondary change into that, namely, nix/*.hh into lix/libexpr/*.hh and such. This should not cause additional breakage.

This would be compatible with our plans to rename the header references internally, and would remain compatible if we use pkg-config to change the -I to include lix/libexpr etc also.

Thoughts on this approach? Should we just ship the nix/ -> lix/ now as in the CL and defer the libexpr/ part? The thought I have is that people who are using nix/ include paths already will have a breakage with this, but not those using #include <value.hh> etc, and we might as well execute our other desired change to those now, externally, so that only breaks once. The internal part would still be a second change.

External clients and internal clients could be fixed from the single-level to the multi-level with a clang-tidy automated refactor we already have the code for.

OK so there is the approach suggested in the CL, which is *just* nix -> lix externally. But we could actually also squish a secondary change into that, namely, `nix/*.hh` into `lix/libexpr/*.hh` and such. This should not cause additional breakage. This would be compatible with our plans to rename the header references internally, and would remain compatible if we use pkg-config to change the `-I` to include `lix/libexpr` etc also. Thoughts on this approach? Should we just ship the `nix/` -> `lix/` now as in the CL and defer the `libexpr/` part? The thought I have is that people who are using `nix/` include paths already will have a breakage with this, but not those using `#include <value.hh>` etc, and we might as well execute our other desired change to those now, *externally*, so that only breaks once. The internal part would still be a second change. External clients and internal clients could be fixed from the single-level to the multi-level with a clang-tidy automated refactor we already have the code for.

👍 2