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

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

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

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
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
jade added this to the Release engineering project 2024-05-09 06:42:11 +00:00
jade added the
release-blocker
label 2024-05-09 06:42:21 +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.

imo this needs to be complete for release to prevent anyone writing bad lix detection code that will later need to be dealt with.
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
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.
Sign in to join this conversation.
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#279
No description provided.