Closed stefanseefeld closed 1 month ago
Even more efficient is to use the binary release. We encourage the use of compiled versions of the tool, and would rather not support the compiling of Mr. Docs by end-users. That said, for supporters, maintainers, and package managers, we publish compiled versions of Clang/LLVM libraries, as this is used to support Continuous Integration (via GitHub Actions) and so that developers don't have to rebuild LLVM
(In fact, I'm trying to get a grasp of the code to evaluate whether I can & want to contribute, so I don't think my request should be considered from an "end-user" :-) )
I'm trying to get a grasp of the code to evaluate whether I can & want to contribute
Hah! Well, that's fair. Yes compiling LLVM is a pain but we use it. There are prebuilt libraries available for development. Also note, compiling LLVM is not enough - we only support a specific version of the library, usually close to the tip of their developmental branch. In other words the tip of the Mr. Docs. master and develop branches require a specific version of LLVM in order to assure correct compilation and behavior.
We chose this route because it makes development far easier than promising to support working with "official" point releases of the upstream libraries. And also we don't have to support as many build environments as platforms. This is a bit different than how Boost libraries are structured.
I understand the need for as of yet unreleased dependency versions. I'm really just curious about the choice of LLVM vs CLang. I'd expect a code-analysis tool such as mrdocs to only require a compiler frontend, rather than a full toolchain.
(As to supporting developers, it would be great if there were instructions for building - or even downloading - a docker image that contains prerequisites already pre-installed.)
I'd expect a code-analysis tool such as mrdocs to only require a compiler frontend, rather than a full toolchain.
We are using quite a lot from LLVM though, such as the YML parser. Here are all the LLVM includes we use:
#include <llvm/ADT/ArrayRef.h>
#include <llvm/ADT/DenseMap.h>
#include <llvm/ADT/Hashing.h>
#include <llvm/ADT/IndexedMap.h>
#include <llvm/ADT/STLExtras.h>
#include <llvm/ADT/SmallString.h>
#include <llvm/ADT/SmallVector.h>
#include <llvm/ADT/StringExtras.h>
#include <llvm/ADT/StringMap.h>
#include <llvm/ADT/StringRef.h>
#include <llvm/Bitstream/BitCodeEnums.h>
#include <llvm/Bitstream/BitstreamReader.h>
#include <llvm/Bitstream/BitstreamWriter.h>
#include <llvm/Config/llvm-config.h>
#include <llvm/Option/ArgList.h>
#include <llvm/Option/OptSpecifier.h>
#include <llvm/Option/OptTable.h>
#include <llvm/Support/CommandLine.h>
#include <llvm/Support/Error.h>
#include <llvm/Support/ErrorHandling.h>
#include <llvm/Support/ErrorOr.h>
#include <llvm/Support/FileSystem.h>
#include <llvm/Support/JSON.h>
#include <llvm/Support/MemoryBuffer.h>
#include <llvm/Support/Mutex.h>
#include <llvm/Support/Path.h>
#include <llvm/Support/PrettyStackTrace.h>
#include <llvm/Support/Process.h>
#include <llvm/Support/Program.h>
#include <llvm/Support/Regex.h>
#include <llvm/Support/SHA1.h>
#include <llvm/Support/Signals.h>
#include <llvm/Support/SourceMgr.h>
#include <llvm/Support/ThreadPool.h>
#include <llvm/Support/Threading.h>
#include <llvm/Support/VirtualFileSystem.h>
#include <llvm/Support/YAMLParser.h>
#include <llvm/Support/YAMLTraits.h>
#include <llvm/Support/raw_ostream.h>
it would be great if there were instructions for building - or even downloading - a docker image that contains prerequisites already pre-installed
Not a bad idea!
What is the reason for the LLVM dependency (as opposed to a much leaner CLang dependency) ? The LLVM repo is huge, and thus stripping it down to only the parts that mrdocs truly needs would be more efficient.