[low priority] Integrate into Compiler Explorer

[neatudarius]

Integrate iterator_interface into Compiler Explorer

• Initial integration with Compiler Explorer (trunk version, automated nigthly clone)
• Decide how versioning and releases
• Release first version

Check progress from bemanproject/optional#21

[changkhothuychung]

I wanna try this, but I haven't integrated to Compiler Explorer before. Any instructions that I can start with?

[neatudarius]

I wanna try this, but I haven't integrated to Compiler Explorer before. Any instructions that I can start with?

Sure! Thanks for help!

Note: We can do only 1st task from attach issue. OK?
Instructions are very simple. Check this example that I did for optional - bemanproject/optional#21 (comment):

• you need to create 2 external issues (similar to optional26)
• each issue will have a PR (similar to optional26)
  Official Compiler Explorer docs here: https://github.com/compiler-explorer/compiler-explorer/blob/main/docs/AddingALibrary.md.

PS: I will create PRs needed for optional26 after library renaming.

[changkhothuychung]

Thanks! Will work on it soon.

[changkhothuychung]

Open issues:

• [LIB REQUEST]: Add Beman.iterator_interface library into Compiler Explorer compiler-explorer/compiler-explorer#7059
• Add Beman.iterator_interface library into Compiler Explorer compiler-explorer/infra#1445

[changkhothuychung]

PR's created

• Add Beman.iterator library trunk version compiler-explorer/compiler-explorer#7060
• Add Beman.iterator library trunk version compiler-explorer/infra#1446

@neatudarius can you review if I am missing something? Thanks!

[neatudarius]

PR's created

• Add Beman.iterator library trunk version compiler-explorer/compiler-explorer#7060
• Add Beman.iterator library trunk version compiler-explorer/infra#1446

@neatudarius can you review if I am missing something? Thanks!

Sorry for late reply - can we push small patches to rename there to beman_iterator_interface? We should match the full name. Maybe we'll have multiple libraries for iterators in Beman.

[neatudarius]

@changkhothuychung , left one comment on your PRs from compiler explorer repos.

I have a WIP PR to make sure iterator_interfaces follows all Beman Standard rules:

[neatudarius]

Left comments on PRs

• rename from beman_iterator to beman_iterator_interace compiler-explorer/compiler-explorer#7084 - LGTM, should be ready to merge
• rename beman_iterator to beman_iterator_interface compiler-explorer/infra#1453 - I think this branch is broken (https://github.com/compiler-explorer/infra/pull/1453/files#r1837618987 - ), and mostly the confusion is inside the iterator_interface docs (I will fix that): cloning repo is not enough, even it's a header-only library! We need to run cmake to translate and install config.hpp.in to config.hpp.

@changkhothuychung , can you help updating and testing that PR? @camio may include a link to Compiler Explorer in his presenation from Meeting C++ Berlin (this week), if the deployment is table. Thanks!

CC: @camio @RaduNichita

[neatudarius]

I see that godbolt developers applied the fix on the PR and merged them. We'll way for the nightly sync. Thanks all!

[partouf]

Couple of things going on:

1. Non-blocking issue -> I had to remove the examples directory from CMake, because it caused cmake --install to fail https://github.com/compiler-explorer/infra/blob/main/bin/yaml/libraries.yaml#L1037
2. The installation does not contain a root config.hpp as required here https://github.com/beman-project/iterator_interface/blob/main/include/beman/iterator_interface/iterator_interface.hpp#L7

The cmake --install package that we make only contains the following:

• include/beman/iterator_interface/detail/stl_interfaces/config.hpp
• include/beman/iterator_interface/detail/stl_interfaces/fwd.hpp
• include/beman/iterator_interface/detail/stl_interfaces/iterator_interface.hpp
• include/beman/iterator_interface/iterator_interface.hpp
• include/beman/iterator_interface/iterator_interface_access.hpp
• lib/libbeman.iterator_interface.a

If I check the cmake logging, I do not see it creating config.hpp

Now live -> https://godbolt.org/z/Yo4954GYW

---

For the record, this is our (generated) script to build with cmake so you can reproduce:

#!/bin/sh

export CC=/opt/compiler-explorer/gcc-14.2.0/bin/gcc
export CXX=/opt/compiler-explorer/gcc-14.2.0/bin/g++
export LD_LIBRARY_PATH=""
export LDFLAGS="-L/opt/compiler-explorer/gcc-14.2.0/lib64 -L/opt/compiler-explorer/gcc-14.2.0/lib  -Wl,-rpath=/opt/compiler-explorer/gcc-14.2.0/lib64 -Wl,-rpath=/opt/compiler-explorer/gcc-14.2.0/lib "
export NUMCPUS="$(nproc)"
cmake --install-prefix "/opt/compiler-explorer/staging/448b6844-3a42-456e-a9f0-12d5ca8e1e8e/install"  "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DCMAKE_SYSTEM_PROCESSOR=x86_64" "-DCMAKE_CXX_COMPILER_TARGET=x86_64-linux-gnu" "-DCMAKE_C_COMPILER_TARGET=x86_64-linux-gnu" "-DCMAKE_ASM_COMPILER_TARGET=x86_64-linux-gnu" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN=/opt/compiler-explorer/gcc-14.2.0" "-DCMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN=/opt/compiler-explorer/gcc-14.2.0"  "-DCMAKE_CXX_FLAGS_DEBUG=    " -DBUILD_TESTING=OFF /opt/compiler-explorer/libs/beman_iterator_interface/main > cecmakelog.txt 2>&1
cmake --build . -j$NUMCPUS --target=beman.iterator_interface > cemakelog_0.txt 2>&1
cmake --build . -j$NUMCPUS --target=beman.iterator_interfaced > cemakelog_1.txt 2>&1
libsfound=$(find . -iname 'lib*.a')
if [ "$libsfound" = "" ]; then
  cmake --build . -j$NUMCPUS > cemakelog_2.txt 2>&1
fi
cmake --install . > ceinstall_0.txt 2>&1

Can send you the logging as well if needed

[steve-downey]

We're mixing FILE_SET and target_include_directory, so we don't know to install the generated header file.
https://github.com/beman-project/iterator_interface/blob/d6efb25da89a628844bae590e3ceea7245a73bca/CMakeLists.txt#L71

Also, https://github.com/beman-project/iterator_interface/blob/d6efb25da89a628844bae590e3ceea7245a73bca/include/beman/iterator_interface/detail/stl_interfaces/config.hpp has feature checks, so the config won't describe a compiled artifact. This is, of course, why building everything consistently within a distro is a good idea, but it can be a subtle source of bugs for shipped binaries.

[partouf]

I'm looking at a (slightly complicated) example https://github.com/kokkos/kokkos/blob/7ff4042fd2dc1d1fe6ae280179fc693ad6dac6ac/cmake/kokkos_install.cmake#L51

and they do it with
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/KokkosCore_config.h DESTINATION ${KOKKOS_HEADER_DIR})

the generated config header might be written to CMAKE_CURRENT_BINARY_DIR?