Cmake #25
Cmake #25
Conversation
Fixes compilation with gcc 4.7 array.h: In instantiation of ‘void ArrayStack<T>::push(const T&) [with T = BPBox*]’: array.h:372:32: required from ‘void ObjArrayStack<T>::push(T*) [with T = BPBox]’ boxprint.cc:371:39: required from here array.h:261:7: error: ‘setIndexDoubler’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] array.h:261:7: note: declarations in dependent base ‘GrowArray<BPBox*>’ are not found by unqualified lookup array.h:261:7: note: use ‘this->setIndexDoubler’ instead
Where "modern" is bison 3.* or so.
|
This work has been done a couple times already it would seem :) https://github.com/KubaO/elkhound is cloned from a repo that had cmake transition done in 2019. Tim Wanders did that work, according to the repo messages. It looks like elkhound is used by text adventure game aficionados to parse the adventures. I've done some work on it so that it's self-contained with MSVC - winflex and winbison are included as a part of the build. Not used on Unix of course. Thanks to cmake, the root folder of the repo can be opened with recent versions of Visual Studio. I've also dragged a lot of the code into the next decade. My goal is to keep it building with C++14. There were a couple little bugs here and there I caught - related to 64-bit compatibility and heisenbugs. I dropped all the containers in smbase (yes, all of them) and replaced those with C++ standard library. ASTList is a thin wrapper around std::vector, kept just to avoid having to do mechanical modifications that cause noise in the diffs. This took some work to keep the whole thing working correctly (I hope). The changes consist of small self-contained commits, and my intention was to keep the thing building and passing tests for every commit. There are 230 commits done over the last month's worth of evenings :) I needed a GLR parser nicer to use than Bison, and that's how I found elkhound. The original code used linked lists a lot and that's a performance killer on modern systems - at least with typical allocators. Where I could, I moved from lists of pointers to vectors of ideally values, or pointers if absolutely necessary. There are very few places where std::forward_list and std::list had to be used, and I'm not convinced those will stay that way. I've also included fmt::format, and a free-standing implementation of string_view. The code is being slowly migrated to use those as/when needed. The overall idea is to use movable values to where they help maintain performance while obviating old optimizations. E.g. I've carefully de-optimized the GLR core to make the code readable by the average person (like myself :). The generated code is still excellent due to man-centuries of effort spent on modern compilers :) Long-term, I imagine this should use the excellent mimalloc memory allocator, since it provides very lightweight heaps, with excellent locality based on object size; creating and destroying them often is no problem. |
I've integrated a few PR's, as well as started on a CMake build system, which can successfully build astgen, elkhound, and elsa/ccparse.