Devel headers #18807
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -151,3 +151,10 @@ Description: FRRouting suite - GRPC interface | |
| This provides the GRPC interface to the daemons. | ||
| Build-Profiles: <pkg.frr.grpc> | ||
|
|
||
| Package: frr-dev | ||
| Architecture: any | ||
| Section: libdevel | ||
| Depends: ${misc:Depends}, frr (= ${binary:Version}) | ||
| Description: Development files for FRRouting | ||
| This package contains the development files (headers and static libraries) | ||
| necessary to build software that links against FRR internals. | ||
|
There was a problem hiding this comment. Second (independent) NAK of two: you're saying in your own description that you wrote "links against FRR internals." This is counter to the purpose of a Further, I would apply the "test requirement" here: without tests, this will simply break. There are test tools for this, abicc and abidiff: https://lvc.github.io/abi-compliance-checker/ https://sourceware.org/libabigail/manual/abidiff.html Considering that there is a better solution available (comment below), this simply should not be done. There was a problem hiding this comment. This PR is a follow-up to the initial PoC proposing a new dplane plugin, which was submitted to get community input on integration. In the weekly call, we agreed the plugin must remain out-of-tree. However, building it is currently not possible due to the broken frr-devel package on Red Hat and its absence on Debian. This PR fixes that. There’s no claim of ABI stability — just the need to support out-of-tree development in a practical, working state. |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| usr/include/frr/*.h | ||
| usr/include/frr/*/*.h | ||
| usr/lib/*/frr/*.so |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,2 +1,2 @@ | ||
| usr/lib/*/frr/libfrrsnmp.so.* | ||
| usr/lib/*/frr/modules/*_snmp.so |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First NAK of two: a
config.hfrom autoconf should never be installed or depended on by development headers. This is discussed in https://sourceware.org/autobook/autobook/autobook_66.html#Installing-Header-FilesIn the case of FRR, it is primarily
lib/frratomic.hthat causes this dependency. The reasons for this are that the use of atomic operations in Quagga began before ISO C11 was widely available. This is no longer a problem and the correct fix is to simply remove the compatibility handling in that file, which then meansconfig.hdoes not need to be installed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the reference — it's a valid point that exposing config.h in installed headers can lead to conflicts.
That said, the issue in FRR isn't limited to frratomic.h. Several headers use #ifdef HAVE_... checks, which makes some form of config header necessary. Removing the atomics compatibility code alone doesn't fully eliminate this dependency.
Renaming config.h (e.g., to frr_config.h) is a useful step to avoid name collisions and makes it safer to include in installed headers, though it still exposes some internal build configuration and ties the headers to specific platform checks.