You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was trying to look at contributing an AIORI backend that solves #397. However I quickly realized that for such a backend to be useful, some IOR headers should be installed (namely the ones that an implementation of an AIORI would need to include). This is however not trivial, for multiple reasons:
There is no clear public and private headers; ior.h includes things like option.h, iordef.h, etc. and I don't think all these headers contain things that are useful to AIORI implementations, and most headers contain definitions that look like they should be private, and other definitions that look like they should be public;
Installing all the headers isn't an option because many headers have pretty generic names (like option.h). Ideally what we would really want is a single, self-contained ior.h (or at most two headers: ior.h, with functions to embed IOR in a code, and aiori.h, with the definitions necessary to write a backend);
Even ior.h contains things that should not be in this header (e.g typedefs and #ifdef related to librados, or to hdfs, which should really be in their respective backend implementation, not in a public header). Even including config.h, which is generated by autotools, is bad practice. It should be included in .c files, not in a public header.
I tried to do some cleanup but quickly abandoned, also mainly because I have no way to test that the changes I'm making still allow everything to build correctly without having a proper procedure to build IOR with every single backend it currently has.
If you have a Docker image that includes everything needed to build IOR with all possible backends, I'm happy to try again, but otherwise someone more knowledgeable than me about IOR should probably start this refactoring.
The text was updated successfully, but these errors were encountered:
Sounds about right. I did start some refactoring but as you point out, it isn't done.
For testing, I suggest: testing/docker/ubuntu22.04-all-backends/Dockerfile
It doesn't build all backends, yet, but 3. It can be extended... build-hdfs.sh has the recipes for HDFS.
I was trying to look at contributing an AIORI backend that solves #397. However I quickly realized that for such a backend to be useful, some IOR headers should be installed (namely the ones that an implementation of an AIORI would need to include). This is however not trivial, for multiple reasons:
ior.h
includes things likeoption.h
,iordef.h
, etc. and I don't think all these headers contain things that are useful to AIORI implementations, and most headers contain definitions that look like they should be private, and other definitions that look like they should be public;option.h
). Ideally what we would really want is a single, self-containedior.h
(or at most two headers:ior.h
, with functions to embed IOR in a code, andaiori.h
, with the definitions necessary to write a backend);ior.h
contains things that should not be in this header (e.g typedefs and #ifdef related to librados, or to hdfs, which should really be in their respective backend implementation, not in a public header). Even includingconfig.h
, which is generated by autotools, is bad practice. It should be included in .c files, not in a public header.I tried to do some cleanup but quickly abandoned, also mainly because I have no way to test that the changes I'm making still allow everything to build correctly without having a proper procedure to build IOR with every single backend it currently has.
If you have a Docker image that includes everything needed to build IOR with all possible backends, I'm happy to try again, but otherwise someone more knowledgeable than me about IOR should probably start this refactoring.
The text was updated successfully, but these errors were encountered: