heitzmann/gdstk

Allow external qhull?

Closed this issue · 4 comments

Would it be possible to handle qhull in the cmake configuration more like zlib is handled, where it is allowed for cmake to use an existing an installation rather than the submodule? conda-forge prefers dynamically linking against other packages rather than statically linking. There is already a qhull package in conda-forge, but when building with conda cmake currently fails trying to handle the external/CMakelists.txt for qhull (see also the conda-forge PR):

  CMake Error at external/CMakeLists.txt:58 (add_library):
    Cannot find source file:

      qhull/src/libqhull_r/global_r.c

    Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
    .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
    .f95 .f03 .hip .ispc


  CMake Error at external/CMakeLists.txt:58 (add_library):
    No SOURCES given to target: qhullstatic_r

Done in v.0.9.45

You'll might have to make sure qhull is installed as a dependency now, but it should work just fine.

Thanks! The qhull linking seems to be working now, but there are other problems with the conda build. It seems like the definition of __STDC_FORMAT_MACROS is getting disrupted because the Linux builds fail (see here) with:

  [ 15%] Building CXX object src/CMakeFiles/gdstk.dir/cell.cpp.o
  In file included from /home/conda/feedstock_root/build_artifacts/gdstk_1697168405023/work/gdstk/include/gdstk/cell.hpp:18,
                   from /home/conda/feedstock_root/build_artifacts/gdstk_1697168405023/work/gdstk/src/cell.cpp:16:
  /home/conda/feedstock_root/build_artifacts/gdstk_1697168405023/work/gdstk/include/gdstk/array.hpp: In member function 'void gdstk::Array<T>::print(bool) const':
  /home/conda/feedstock_root/build_artifacts/gdstk_1697168405023/work/gdstk/include/gdstk/array.hpp:38:38: error: expected ')' before 'PRIu64'
     38 |         printf("Array <%p>, count %" PRIu64 "/%" PRIu64 "\n", this, count, capacity);

Also, oddly, one Windows and one Mac test run fail with:

>           lib.write_gds(tmpdir / "path_test.gds")
E           TypeError: Can't convert 'LocalPath' object to str implicitly

but the others pass.

Should I open a new issue? You could also comment in conda-forge/gdstk-feedstock#44.

Maybe the issue is what is described here where one of the other headers is including inttypes.h before __STDC_FORMAT_MACROS is set. The Mac build logs do complain about __STDC_FORMAT_MACROS being redefined. Maybe different toolchains have different tolerance for redefining macros.

Working now, so I will close.

I realized that the test error I quoted above only affects PyPy. It would probably be fixed by changing to lib.write_gds(str(tmpdir / "path_test.gds")) if you cared about that (not sure there is much overlap of pypy users and gdstk users).