#include "config.h" in .h files

Dev
1

I was writing a new C test to run from test_c_utils.py and I found that #include “config.h” is a problem for such tests, as we don’t know for sure where the config file is when the test is run. I see several solutions:

  1. Provide some environment variable to the test scripts which tells where to find config.h so the appropriate -I flag can be provided to the compiler.
  2. Export and install config.h in include/graphviz/config.h and include it as <graphviz/config.h> (Though this might also need an env var to find, though perhaps we can assume we can find it from $PATH: look for dot executable and navigate from there.)
  3. Remove #include “config.h” from all .h files and use NO_CONFIG preprocessor definiition as already done in list.c to support test_list.c.
    • Note that list.c is lucky in that it has a small include list, and misses the list below
    • Currently, a small number of .h files have #include “config.h”, and need to be fixed:
      • cmd/gvedit/csettings.h
        cmd/tools/convert.h
        lib/cgraph/cghdr.h
        lib/cgraph/ingraphs.h
        lib/common/colorprocs.h
        lib/common/render.h
        lib/fdpgen/grid.h
        lib/neatogen/neato.h
        lib/neatogen/sparsegraph.h
        lib/sfdpgen/sfdp.h
        lib/sfio/sfhdr.h
        lib/sfio/sfio.h
        plugin.demo/xgtk/src/support.h
    • Also, the generated parser files currently only see config.h because it’s included by some .h files they include. This must also be fixed, as without seeing the config.h they are buggy.:
      • cmd/tools/gmlparse.y
        lib/cgraph/grammar.y
        lib/cgraph/scan.l
        lib/common/htmlparse.y
        lib/expr/exparse.y

I Vote for #3 and can send out an MR if supported, though perhaps there are reasons to go with a different solution. Please let me know.

-Brian

2

I don’t have a definitive opinion, but some thoughts:

  • (1) isn’t ideal because the test suite is intended to be runnable against an installed Graphviz and source tree without having actually built Graphviz locally. I.e. config.h may not exist anywhere on disk. (I say “intended” because whether this configuration actually works currently is questionable).
  • (2) is a subtle foot gun. Shipping your config.h often results in it being included in some other unrelated software’s build against their will. The main offender that comes to mind is PHP that ships its config.h. Because config.h is full of non-namespaced macros that were never intended to be exported, you suddenly find yourself playing whackamole with this interloper’s HAVE_FOO that doesn’t match what your local build should have discovered for HAVE_FOO. You can see some desperate attempts to work around this in tclpkg/gv/gv_php_init.c. I would very much like to avoid inflicting this pain on someone else.
3

So, you’re ok with #3. Sounds like a plan.