Apparently parts of our docs are very outdated. I've started to update some of them, but it will be a while before they're all done. I wish I had gotten to the Compile doc sooner; I can imagine parts of it have confused people recently. Some updates are at
https://docs.dfhack.org/en/latest/docs/Compile.html if anyone would like to provide feedback (note that "latest" on ReadTheDocs corresponds to "develop" on GitHub, and "stable" = "master"). I may try to backport some of these changes to the master/stable version before the next release, if a lot of people are looking there for instructions too.
Yeah, that makes sense. Thanks for the link to the docs. Interesting that the search engine in the page couldn't pull that up...
I kind of cheated and searched for "eggs-fertile" because I knew what it was, but even then, it didn't show up in the first couple results. Searching for just "fertile" pulls up the plugins page as expected, but result #5 out of 5, and quotes the nestboxes plugin. The Sphinx search engine isn't always the best (but also neither are our docs).
Yeah, I'm using the default branch as that is what the compile doc said was the stable branch. There is a possibility that I did the original cloning before you made the change. How long ago did you change the default branch to the development branch?
Maybe in March? I don't really know. That particular part of the docs was last updated in 2015, and I realized as soon as I posted that it was probably the source of the confusion.
https://docs.dfhack.org/en/latest/docs/Compile.html#how-to-get-the-code should be up-to-date now (see my comment about the URL earlier in this post) - does that help? I'm happy to tweak it further.
Well I ran git submodule update from the dfhack directory. It compiled just fine. I did have to edit the DFHack script to include a reference to libz.so.1, though I had to do that when I originally installed dfhack too (also had to make a similar change to ./df in order to get that to work).
Still says I'm using the beta1, though for some reason.
The DFHack script you're referring to is the "dfhack" launcher in the DF folder, right? You should also be able to set the PRELOAD_LIB environment variable to do that (instead of editing the launcher), and you can set that in ~/.dfhackrc or /path/to/df/.dfhackrc. (Yet another mostly-undocumented feature that we should address...)
Update:
Still says I'm using the beta1, though for some reason.
Not sure on this. Things you could try: running "git describe --tags" in the source folder, or running "install-info" from the DFHack console.
Edit2:
Just tried running git checkout master and then git submodule update from the dfhack directory.
git submodule update gave me this error message:
Submodule path 'depends/clsocket': checked out '6a9153d053a250be34996b3fd86ac1166c3e17cb'
Submodule path 'library/xml': checked out '4053321b202a29f667d64d824ba8339ec1b1df4f'
error: The following untracked working tree files would be overwritten by checkout:
agui/include/Agui/ActionEvent.hpp
agui/include/Agui/ActionListener.hpp
agui/include/Agui/Agui.hpp
-snip-
Any Ideas. IIRC, I've had problems with Agui before. It's not available for debian based systems when using the package manager, and I'm not sure how to install libraries by hand. There used to be some instructions on how to get Agui, Isoworld, and Stonesense working, but they stopped working in newer versions. Usually, I just set ccmake to not compile Isoworld and Stonesense.
I'm assuming you set BUILD_ISOWORLD to ON? I've probably never run into this because I've never built Isoworld locally before. Does it still work? (I honestly don't know; it defaults to OFF in plugins/CMakeLists.txt, and I don't think we distribute it currently.)
Did you do anything special to get a copy of isoworld besides cloning DFHack? I'm mostly confused because at least the first one, agui/include/Agui/ActionEvent.hpp, exists in plugins/isoworld on my end, and Git seems to know about them. Actually, it looks like these files were only added to the repo in January 2020 (they were probably ignored before then) - is your clone earlier than that? Those files are pretty easy to replace, assuming you haven't changed them at all, so you could just try adding "--force" to the "git submodule update" command and see if that works.