In the commit [1] that introduces statx structure as an out arg from glfs APIs, there is a need to provide a compatible header for statx, when the base distribution does not still support statx (say centos7). The header is provided as libglusterfs/src/compat-statx.h and is packaged with the glusterfs-devel RPM (as are other libglusterfs headers, and the api-devel package depends on this package, so all this is fine so far). The issue at hand is that, the inclusion of the new header [2] is done using the user specified format for header inclusion (i.e "compat-statx.h") [3] and should really be a system header file that comes in with the glusterfs-devel package. When included as <glusterfs/compat-statx.h> instead of the current "compat-statx.h" though, the compilation fails, as there is no directory named glusterfs, which is added to the search path during compilation, that contains this header. For solutions, I tried adding a symlink within libglusterfs/src/ named glusterfs that points to src, thus providing the directory under which compat-statx.h can be found. This works when compiling the code, but not when building packages, as the symlink does not transfer (or I did not write enough code to make that happen). In reality I do not like this solution to really use this framework. The mail is to solicit inputs on how we can solve the compile and packaging build time dependency and retain the inclusion as a system header than a user header as it currently stands. My thought is as follows: - Create a similar structure that the packaging lays out the headers on a system and move the headers in there, thus having a cleaner build and package than other hacks like above. - IOW, create glusterfs directory under libglusterfs/src and move relevant headers that are included in the packaging in there, and similarly move headers in api/src to a directory like api/src/glusterfs/api/ such that when appropriate search paths are provided these can be included in the right manner as system headers and not user headers. This work can also help xlator development outside the tree, and also help with providing a pkgconfig for glusterffs-devel IMO. Comments and other thoughts? Shyam [1] Commit introducing statx: https://review.gluster.org/c/glusterfs/+/19802 [2] Inclusion of the header: https://review.gluster.org/c/glusterfs/+/19802/9/api/src/glfs.h#54 [3] Include syntax from gcc docs: https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
