libnvme: add accessor code generation

[martin-belanger]

This adds a code generator that parses struct definitions and generates accessor functions (setters/getters).

Note that the generated code is added to libnvme.so, but it is not currently being called by anything. Also, the generated code is not added to the libnvme.map file. So, basically it is dead code...

The next step will be to actually invoke the generated functions and add them to the libnvme.map file. I need to check if we are allowed to have more than one *.map files. It would be easier to generate the map file for the accessor functions separately from the libnvme.map.

[igaw]

Looks good. I think we need also solve the integration into libnvme before merging. I've experimented a bit around:

https://github.com/igaw/nvme-cli/tree/accessor-generator

This needs cleanup and the last problem sovled, how to use the header file.

(btw, we should rename libnvme.map to libnvme.ld and fixup meson accordingly.)

[martin-belanger]

@igaw - I’ve got it working now. It took a bit of time, mostly due to a lot of testing and re-testing.

There were two main areas that needed work:

-Figuring out how to tell Meson where files are located, especially when building libnvme standalone and installing it in a non-standard location.
-Generating and using the linker map file for the accessor functions.

Telling meson where files are located:
In the end, the key was to rely on Meson’s dependency objects rather than manually setting include directories or linker search paths. In Meson, explicitly manipulating search paths is usually a sign that something isn’t being modeled correctly. By setting up proper dependencies—using dependency(), declare_dependency(), or even compiler.find_library()—Meson is able to handle paths and ordering correctly.

This led to the less pleasant part: a fairly broad refactoring of the meson.build files. This wasn’t limited to the accessor work; I updated anything that was manually tweaking include paths or library paths without using a proper dependency object. At this point, almost everything relies on dependency objects to locate headers and libraries.

Linker map files:
You had already done most of the heavy lifting here. I built on your generator changes so that a map file for the accessor code is generated, and I found a way to use that generated map file directly without merging it into libnvme.map, which simplifies things quite a bit.

That said, this does raise a longer-term concern. As the generated accessors evolve, we’ll likely need multiple versioned sections in the map file (one per release). Right now, everything ends up under LIBNVME_ACCESSORS_3_0. I’m not sure how we could automatically generate a map file with multiple versioned sections. One alternative might be to generate the accessor code once, commit it to the source tree, and then maintain the accessor map file manually so we can clearly control which symbols belong to which version.

Feel free to play around with the latest changes and see if they meet your expectations. Let me know if there’s anything else you’d like me to look into.

[martin-belanger]

@igaw — I fixed the compilation issue from my last commit. When building libnvme separately from nvme-cli, there are several cases to handle—for example, whether libnvme is installed in a standard location (/usr, /usr/local) or in a non-standard prefix.

For non-standard install locations, the compiler must be explicitly told where to find libnvme.so and the libnvme headers using absolute paths, rather than relying on Meson’s automatic discovery.

This took some experimentation to get right, but I learned a few new things about Meson along the way. Figuring this out was a lot of fun... 😜