# \#include "config.h" in .h files

**URL:** https://forum.graphviz.org/t/include-config-h-in-h-files/3327
**Category:** Dev
**Created:** [April 8, 2026, 3:50am UTC](https://forum.graphviz.org/t/include-config-h-in-h-files/3327 "2026-04-08T03:50:14Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![brianrmurphy](https://avatars.discourse-cdn.com/v4/letter/b/ce73a5/32.png) [@brianrmurphy](https://forum.graphviz.org/u/brianrmurphy)
#### Post date: [April 8, 2026, 3:50am UTC](https://forum.graphviz.org/t/include-config-h-in-h-files/3327/1 "2026-04-08T03:50:14Z")

</div>

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

---

<div class="post-metadata">

### Author: ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)
#### Post date: [April 9, 2026, 7:13am UTC](https://forum.graphviz.org/t/include-config-h-in-h-files/3327/2 "2026-04-09T07:13:20Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![brianrmurphy](https://avatars.discourse-cdn.com/v4/letter/b/ce73a5/32.png) [@brianrmurphy](https://forum.graphviz.org/u/brianrmurphy)
#### Post date: [April 25, 2026, 5:49am UTC](https://forum.graphviz.org/t/include-config-h-in-h-files/3327/3 "2026-04-25T05:49:00Z")

</div>

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