# Problems compiling Rocksdb

**URL:** <https://swi-prolog.discourse.group/t/problems-compiling-rocksdb/5701>\
**Category:** Pack\
**Created:** [August 19, 2022, 6:02pm UTC](https://swi-prolog.discourse.group/t/problems-compiling-rocksdb/5701 "2022-08-19T18:02:57Z")\
**Posts on this page:** 1\
**Showing post:** 36

<div class="post-metadata">

**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\
**Post date:** [August 22, 2022, 6:27pm UTC](https://swi-prolog.discourse.group/t/problems-compiling-rocksdb/5701/36 "2022-08-22T18:27:52Z")

</div>

> [@peter.ludemann](#):
>
> From looking at the source of `prolog_pack.pl`, I don’t see where the 2nd argument of `is_foreign_pack/2` is used. As far as I can tell, these files are used to indicate that there are foreign files, but it’s not clear to me what `library/build/tools.pl` uses – according the documentation for build\_steps/3, the appropriate toolchain is used, based on what files exist.

~~Not sure myself at present.~~ I don’t know if you saw [this](https://swi-prolog.discourse.group/t/compiling-with-msys2/3936/24) which list two packs that have CMakeLists.txt. Since Jan W. created one it seems that the intent is for this to work even if it is not yet fully working in the code.

**EDIT**

The code is in directory [library/build](https://github.com/SWI-Prolog/swipl-devel/blob/5a3743ab97ec8960d711cf0dbbfb8f3d90eeb6fd/library/build)

library/build/[tools.pl](https://github.com/SWI-Prolog/swipl-devel/blob/5a3743ab97ec8960d711cf0dbbfb8f3d90eeb6fd/library/build/tools.pl)

> This module implements the build system that is used by pack\_install/1  
> and pack\_rebuild/1. The build system is a plugin based system where each  
> plugin knows about a specific build toolchain. The plugins recognise  
> whether they are applicable based on the existence of files that are  
> unique to the toolchain.

library/build/[cmake.pl](https://github.com/SWI-Prolog/swipl-devel/blob/5a3743ab97ec8960d711cf0dbbfb8f3d90eeb6fd/library/build/cmake.pl)

> Manage a CMake project. This prefers the `ninja` generator if available  
> in `$PATH`.

library/build/[make.pl](https://github.com/SWI-Prolog/swipl-devel/blob/5a3743ab97ec8960d711cf0dbbfb8f3d90eeb6fd/library/build/make.pl)

> This build plugin deals with GNU style packages. It knows about the  
> following programs:
> 
> - automake to create Makefile.in from Makefile.am
> - autoheader to create `config.h.in` from `configure.in`
> - autoconf to create `configure` from `configure.in`
> - `configure` to create `Makefile`
> - `make` for the make step

* * *

> [@peter.ludemann](#):
>
> But I don’t think we’d want packs to require `cmake`.

I don’t think it should be a requirement but it would be nice to have them. I really did not understand [CMake](https://cmake.org/) until a few weeks ago when I took time to due the [tutorial](https://cmake.org/cmake/help/latest/guide/tutorial/index.html) and then do it with a few other [generators](https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) such as Visual Studio 17 2022, Ninja, NMake Makefiles, Unix Makefiles, MSYS Makefiles, MinGW Makefiles.

While it does make building more consistent, there is still much work that has to be done to get correct builds, still learning the ropes.

---

_[View the full topic](https://swi-prolog.discourse.group/t/problems-compiling-rocksdb/5701)._