# Header files with the same name

**URL:** https://discourse.vtk.org/t/header-files-with-the-same-name/8549
**Category:** Support
**Created:** [May 23, 2022, 7:15am UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549 "2022-05-23T07:15:34Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![amaclean](https://discourse.vtk.org/user_avatar/discourse.vtk.org/amaclean/32/224_2.png) [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [May 23, 2022, 7:15am UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549/1 "2022-05-23T07:15:34Z")

</div>

I am getting a list of files by modules in the VTK source and I note that `vtkFilterPolicy.h` occurs in both `Accelerators\Vtkm\DataModel`and `Accelerators\Vtkm\Core`. The files only differ in line 20.  
Out of 2997 headers this is the only anomaly I have found.

I had assumed that the VTK header file names were unique. Is this an exception or just an oversight?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [May 23, 2022, 2:03pm UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549/2 "2022-05-23T14:03:37Z")

</div>

These are private headers, so there’s no problem AFAIK.

---

<div class="post-metadata">

### Author: ![amaclean](https://discourse.vtk.org/user_avatar/discourse.vtk.org/amaclean/32/224_2.png) [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [May 23, 2022, 10:50pm UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549/3 "2022-05-23T22:50:29Z")

</div>

Thanks for that, I’m trying to write a better `whatModulesVTK.py`. In this case there might just be an extra module added to the find\_package list.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [May 24, 2022, 12:26pm UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549/4 "2022-05-24T12:26:06Z")

</div>

Private headers should not be in the `.json` file, so why would that interfere?

---

<div class="post-metadata">

### Author: ![amaclean](https://discourse.vtk.org/user_avatar/discourse.vtk.org/amaclean/32/224_2.png) [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [May 24, 2022, 11:44pm UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549/5 "2022-05-24T23:44:41Z")

</div>

This script `WhatModulesVTK.py` uses the VTK source files, not the build, hence the modules.json file is not used. The reason is that it is used to build all the thousand or so CMakeLists.txt files that are used on the vtk-examples web site including examples that use modules not necessarily built by the user who is building the web site. So far no user of the examples has indicated any issues so I am reasonably confident it is producing a useable result.

`WhatModulesVTK.py` in the VTK source doesn´t work for Python3 and I have just finished an upgrade of `WhatModulesVTK.py` in vtk-examples that now uses pathlib.

Woud it be worthwhile upgrading the existing version in the VTK source with the working version from the vtk-examples source? I was considering a MR.

In practice it will be unlikley anyone would use the private headers so I don´t really see it as an issue.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [May 25, 2022, 1:31pm UTC](https://discourse.vtk.org/t/header-files-with-the-same-name/8549/6 "2022-05-25T13:31:10Z")

</div>

> [@amaclean](#):
>
> Woud it be worthwhile upgrading the existing version in the VTK source with the working version from the vtk-examples source? I was considering a MR.

Ideally, these examples wouldn’t need so much churn (i.e., VTK should stop moving classes around in incompatible ways). But while that’s still happening, updating it seems fine to me (it’s an in-repo-only tool anyways).
