Libecap relies on HAVE_CONFIG_H too much

[Amos Jeffries]

When building a host application or an adapter without using autotools:

    /usr/include/libecap/common/registry.h:15:75: error: ‘LIBECAP_VERSION’ was not declared in this scope
    extern bool RegisterVersionedService(adapter::Service *s, const char *v = LIBECAP_VERSION);

----

Original description: libecap/common/registry.h makes use of types defined in libecap/common/autoconf.h but does not automatically add that file.

[Alex Rousskov (rousskov)]

> libecap/common/registry.h makes use of types defined in libecap/common/autoconf.h

Can you give an example of such a type? My quick scan of registry.h did not flag any good candidates, and my autoconf.h does not define any types at all, but I may be looking at a stale copy or something like that.

common/autoconf.h is an internal implementation detail rather than a part of the public library API. That file is automatically included by common/libecap.h which should be included (directly or indirectly) in all other public eCAP header files.

AFAICT, common/registry.h includes common/autoconf.h via common/forward.h which includes common/libecap.h mentioned above. Please correct me if I am wrong.

* If your autoconf.h does define types, then perhaps the bug you are dealing with is related to HAVE_CONFIG_H macro being undefined, preventing common/libecap.h from including common/autoconf.h. IIRC, that autotools macro is supposed to be set via the compiler command of your project. Makefiles generated by autotools do that automatically but YMMV.

* Otherwise, you might be dealing with <tr1/memory> or other legacy code problems instead. Please share more details.

[Amos Jeffries (yadi)]

The specific one my test case highlighted was:

/usr/include/libecap/common/registry.h:15:75: error: ‘LIBECAP_VERSION’ was not declared in this scope
   15 | extern bool RegisterVersionedService(adapter::Service *s, const char *v = LIBECAP_VERSION);

[Amos Jeffries (yadi)]

Minimal test code is this:

test.cc:

  #include <libecap/common/registry.h>

[Amos Jeffries (yadi)]

And no the project being built does not use autotools, nor have the config.h.

[Alex Rousskov (rousskov)]

> error: ‘LIBECAP_VERSION’ was not declared in this scope

Ah, LIBECAP_VERSION is not a "type", but a macro/constant defined in autoconf.h.

> the project being built does not [...] have the config.h.

But libecap (i.e., the library the project is using) does have autoconf.h. The adapter project should not prevent the inclusion of libecap's generated/installed autoconf.h.

When using autotools, this inclusion usually happens automatically because autotools usually define HAVE_CONFIG_H. When not using autotools, you have a few options, including:

1. Defining HAVE_CONFIG_H macro manually (so that libecap includes its own autoconf.h). In a sense, you would be telling libecap that it does have autoconf.h, which is true. Your adapter code does not need to use that macro, of course.

2. Including libecap autoconf.h manually, before any libecap files. This is kind of a hack because, ideally, you should not depend on how/when libecap includes that internal header file.

3. Defining the constants defined in libecap autoconf.h using compiler `-D` flags or equivalent. This is obviously a huge hack because you should not know which constants are defined in that internal header file.

Long-term, I suspect that libecap should not use HAVE_CONFIG_H at all; it should just assume that its (generated) autoconf.h file is always available. I do not know whether autotools recommend a different approach for installed libraries. I will edit and leave this bug report open to track that long-term change.

FWIW, it may be easier to build loadable modules using autotools and provided examples/samples than to figure out all the low-level linker/loader commands required for that on a given platform. YMMV.