# Master branch build failure vs2017

**URL:** <https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185>\
**Category:** Development\
**Created:** [July 9, 2024, 2:39am UTC](https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185 "2024-07-09T02:39:10Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [July 9, 2024, 2:39am UTC](https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185/1 "2024-07-09T02:39:10Z")

</div>

I’m seeing a compile error with vs2017, which is still a supported compiler according to the VTK build instructions:

```plaintext
  vtkTableBasedClipCases.cxx
  Internal Compiler Error in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\CL.exe.

```

The error doesn’t give much useful information, but I’ve tracked down the problem to the large arrays in the vtkTableBasedClipCases.h header file, e.g.:

```c++
  static constexpr uint8_t CellCases[] = {
    <26665 elements>
  };

```

It seems that, for vs2017, this array is just too large to be `constexpr` and basically crashes the compiler. As a test, I reduced the size to just a few hundred elements (and similarly reduced other arrays in this header), and the compilation worked just fine.

Would it be reasonable to put the few really huge arrays into the .cxx file, instead of keeping them in the .h file? It would be easier on the compiler, and probably wouldn’t impact performance much.

Edit: it’s probably just two arrays that would have to be moved: `CellCases[26665]` and `CellCasesInsideOut[23879]`.

Edit 2: I’ve confirmed that vs2017 builds after these arrays are moved to the .cxx and declared “const” instead of “constexpr”.

---

<div class="post-metadata">

**Author:** ![mwestphal](https://discourse.vtk.org/user_avatar/discourse.vtk.org/mwestphal/32/19_2.png) [@mwestphal](https://discourse.vtk.org/u/mwestphal)\
**Post date:** [July 9, 2024, 7:52am UTC](https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185/2 "2024-07-09T07:52:09Z")

</div>

FYI @ben.boeckel

---

<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:** [July 9, 2024, 1:10pm UTC](https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185/3 "2024-07-09T13:10:04Z")

</div>

Seems like a reasonable change to me. Note that we usually have data arrays like this in separate files anyways because `clang-format` has historically taken way too long to reformat them. See `vtkEarthSource.cxx` and `vtkEarthSourceData.inl`.

---

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [July 10, 2024, 11:19am UTC](https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185/4 "2024-07-10T11:19:43Z")

</div>

After pulling from master, I found another vs2017 compile failure, this one is due to the recently updated ThirdParty/exodusII package. The file ex\_field\_utils.c uses `restrict`, and vs2017 reports a syntax error as a result. [Here is the line:](https://github.com/sandialabs/seacas/blob/5cc1062/packages/seacas/libraries/exodus/src/ex_field_utils.c#L30)

```c
size_t my_strlcat(char *restrict dst,
                  const char *restrict src,
                  size_t maxlen)

```

Not sure why windows CI doesn’t catch this, perhaps vs2022 is okay with `restrict`?

---

<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:** [July 11, 2024, 9:04pm UTC](https://discourse.vtk.org/t/master-branch-build-failure-vs2017/14185/5 "2024-07-11T21:04:50Z")

</div>

Yeah, VS2022 is probably OK with it. Given the C++17 bump that is pending, we should probably add a mindeps Windows build as well.