Add a New Comment Rich Markup
Jump to the original submission
Just wanted to say, I saw the recent commits to improve INSTALL.md, and I really appreciate them. Thank you. :D
Also, I'm seemingly not able to build the tarball version. When I follow the instructions calling "make" produces this "make: * [Makefile:1193: engine/prim.i] Error 1" error. Should I make this a separate bug, or does someone know where I went wrong?
I'm new to forth, so at the time it never occurred to me that one of the dependencies of the "build-from-source" version would be the outdated version of gforth. (Which I now understand, as forth is traditionally self-hosted.) I just assumed that following the instructions would end up with the latest version added to the path, and it never occurred to me that I'd have any reason to follow the tarball instructions. I guess I didn't expect building something from source to result in multiple versions being installed. Perhaps we could make this more user-friendly by defaulting to the "build from tarball" option. But in the meantime, we can probably close this bug report, since there isn't a bug per-say. We could probably improve the build process, but that's another discussion. I appreciate the discourse & responsiveness, especially as I'm pretty new to forth and will likely have more questions in the future.
Did you read INSTALL.md, section “build from tarball”? It's right there.
That's good to know, I'll try using the "tarball" option later today when I get the chance. Still, it would be nice if the INSTALL.md instructions at least explained this to you.
install-deps.sh does not install the outdated Gforth (nor the fork of Swig), if you set BUILD_FROM to "tarball" before sourcing install-deps.sh.
Including the tarball could help, but perhaps this problem could be solved by using a "chroot" environment. Just install the older Gforth within that "chroot" environment, so that only the newer Gforth will end up installed on the host system. Admittedly, I don't have any experience using the "chroot" command, so maybe it wouldn't work here, but I'll check it out and see if it does. (Also, now I have an account. Woo! :D)
When you build Gforth from the git sources, it uses an existing (outdated) Gforth in various places. That's why it's in the install dependencies. When you build Gforth from the tarball, you don't need an existing Gforth. Maybe we should deliver the tarball with an install-deps.sh that does not install gforth. The way I set up my system is to install the new gforth in /usr/local, and have /usr/local/bin before /usr/bin in the path.
I recently tried to build the latest Gforth from source, but I encountered a problem where the scripts automatically installed the outdated version of Gforth via the "apt" command due to the fact that I was using Debian. I found the source of the problem in the install-deps.sh file, where the same behavior appears to exist for Fedora, Alpine Linux, & OSX.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.12