[Bugs] [Bug 1636297] New: Make it easy to build / host a project which just builds glusterfs translator

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1636297

            Bug ID: 1636297
           Summary: Make it easy to build / host a project which just
                    builds glusterfs translator
           Product: GlusterFS
           Version: mainline
         Component: build
          Severity: high
          Priority: high
          Assignee: bugs at gluster.org
          Reporter: atumball at redhat.com
                CC: bugs at gluster.org, kkeithle at redhat.com,
                    ndevos at redhat.com, srangana at redhat.com



Description of problem:

## What we need?

Today, all the translators which are present in glusterfs, which needs to be
built for glusterfs, has to be in glusterfs repository for it to be building
easily, and working smoothly.

One of the major reason is that, glusterd is in same repo, which manages the
volfile generation, and hence it makes sense!

By keeping volgen as a separate package
(https://github.com/gluster/glusterd2/issues/1190) one can technically have no
dependency on any project, but need to 'place' the translator in the proper
path when they build it, and add their translator in the template.

If we allow developers to have a project for developing translators independent
of glusterfs codebase (ie, using glusterfs-devel package as a dependency), it
will allow the project to proceed faster, adapted well.

## What is the problem?

The challenge I am facing to 'host' a separate project for a new translator is
that, the header files installed in the system are not having a proper
dependency graph!

* I can't just add '#include <glusterfs/xlator.h>' (or similar) and start
writing a translator. 
* There are many macros (including GF_HOST_OS) which are defined through
configure.ac, but are not added in a .h file (not in config.h too). The problem
is, even though we build a specific '-devel' package with a fixed set of
variables, that is not captured, and I have to add all those things again in
configure.ac of new project.
* Some libglusterfs header files depend on .h files generated from RPC
directory, which gets installed in ${includedir}/glusterfs/rpc/${filename}.h,
but are called as '#include "${filename}.h"` in glusterfs codebase. Problem
with this is, I have to provide '-Ipath' option to build, which is not
intuitive.
* Some variables, like 'uuid_t' are not properly resolved even if I include
compat-uuid or uuid.h from include path!


With all these problems, I am yet not successful in hosting my own translator
in a separate repo.

## What is required?

I just want to write a new translator or say compile 'playground/template.so'
as a translator in a separate repo, by making glusterfs-devel package as a
dependency, and technically, I should be able to achieve it, without a lot of
issues.


Version-Release number of selected component (if applicable):
master

How reproducible:
100%


Actual results:
Not easy to build this xlators outside glusterfs repo!

Expected results:
Should be able to do it easily!

Additional info:
This helps us to move the translator code we remove while fixing bug
https://bugzilla.redhat.com/show_bug.cgi?id=1635688 in a separate repo, so,
interested users can continue to use it, and we can continue to keep glusterfs
repo with only maintained codebase!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.