The build on Linux is according to the description in the Readme.md file. Now I needed to build on another machine, which happens to be a Windows box.
I ran the build script in my r3 downloaded executable after which it became clear there was no gcc installed.
How to proceed now? Is the TCC alternative available and even preferrable over gcc? Or is gcc the way to go and how to go on with installing that? Perhaps even use Visual Code?
All things being equal, I'd really hope people would be focusing their attention on the web build.
The questions that you raise here are a good reason why.
It's not in particular your fault that you don't know how to proceed or what choices to make. But the fact that you don't come to the situation armed with preferences and a clear direction of what to do suggests that maybe it's the wrong goal for you.
For Windows, what I do is install Visual Studio (currently 2022 version) and pick the C++ desktop settings to get the MSVC executables. Then I run the "Developer Command Prompt" batch file, which spawns a command prompt that has the necessary executables in the path. (CL.EXE the compiler, NMAKE.EXE the build tool)
I edit in VSCode. Some debugging scenarios are handled better in Visual Studio, but I only bring that out occasionally.
The GitHub Actions runner comes with Visual Studio preinstalled. So it's making the builds using an environment similar to what I have.
-
Visual Studio is big. I have a 2 terabyte hard drive and a fast computer so I tolerate it. While I'm empathetic to people who say "oh no, my hard drive is small, I can't install such a thing" I also have to choose my battles.
-
Using TCC is a fringe exercise that I have actually never done in Windows (I don't think?) Maybe years ago. It might not be working at the moment even on Linux. I've had other more important things to worry about, like...binding.
-
Using the MinGW toolchain is more relevant but also something I haven't been keeping up with. Our MinGW build on the servers was actually cross-compiling, e.g. the MinGW compiler runs on Linux and builds for Windows.
I can't really support the efforts of anyone not savvy enough to sort the issues out on their own. I have a -lot- to do and need to draw the line.
There's a universe of tinkering one can do with the web build, and that's where the relevant future is.
(Or... install a linux virtual machine and you can get all the compilers and such with sudo apt get)
Thanks for answering that Brian. Though probably there are others around that have found their way in achieving the build on W, that could have answered my question. As I am not in the business of reinventing wheels, I do pose such questions here, where other interested minds can find the answer to this issue and save time and energy and some likely frustration.
And focussing on the webbuild? Can the webbuild assist with the building for specific platforms. Where does the webbuild live, what about interaction with the platform, this thing has not gotten a place in my mind where it does make sense over the regular thing. I guess it is a mental block I have to deal with, lack of imagination.
To be clear, I build it every day...and there are GitHub Actions that keep it going, demonstrating 32-bit and 64-bit builds.
%/.github/workflows/windows-msvc-build.yml
For the sake of reassurance, here's some batteries of tests running (stacklessly!) on desktop platforms. I just ran these right now:
- httpd server passing right now on Win, Mac, Linux
- encap mechanics working on Win, Mac, Linux
- stdio and redirection on Win, Mac, Linux
I keep things I care about working as well, which includes "Redbol" versions (I preserved my historical Rebol2 whitespace and USCII scripts, and build them with the emulation "skin" alongside modernized version):
And of course, another heavily-backwards-compatible "skin" called %bootstrap-shim.r is used to simulate building Ren-C itself (in a way that an executable from years ago can also do). It's a rather incredible feat, constantly raising the bar on the already epic flexibility of the system.
So don't fear that any of this isn't working. It is.
It would just take a really big buy-in from someone to get any support at all from me on it.
I don't think anyone would even offer me $25/hr for Windows support. And imagining they would, I don't think it would be a good idea to take it... unless something in their task overlapped things I really felt needed doing anyway.
It is important to be able to be agile and have a codebase that can be built anywhere, with good dependency control and slick interoperability.
But it's important to not make the mistakes Red has made, attempting to cater to the relatively small audience of desktop platforms.
If it were not possible to build on basically any desktop platform, that would be a bad sign. I'm cautious when it comes to things like OpenBSD or Haiku (or even Syllable, for those who remember that).
But whether you can build on any of these platforms (for any particular "you") isn't really something I can get concerned with. Certainly I could only care if you've successfully built some other similarly complex project first on that platform.
One "Supported" "Desktop" Option: Use Cloud Win/Mac/Linux
If you can't take dev matters into your own hands...but are willing to accomplish your task using a GitHub-hosted runner that runs only the latest Ren-C, then you can get support for Windows/Linux/Mac scripts.
For an example, see Graham's PHARMAC:
He just writes a YAML file that says "get me an interpreter" and then has it run his script on a Cloud Linux machine. (It could just as easily be a Windows or Mac runner--as my test runs above demonstrate. But his case uses ghostcript and stuff that is easier to sudo apt install on Linux.)
I've offered the contract with people that if they do this, and demonstrate something has a test and it is working, that for some limited number of such things I will add them to the pool of what I attend to. If a Ren-C change breaks it, I will fix it if it's a bug, or edit your scripts until the green testing lights are back on.
This is a very tailored scenario. Note that in it, I'm not helping you sort out anything related to the process of building Ren-C on your machine, nor any bugs you might find in an .EXE version that's not exactly parallel to what's being delivered on the web right now.
But Really: Be Like @gchiu and Learn The Web
He's doing it and getting the satisfaction of seeing the Repl get better:
A little bit of JavaScript experience won't hurt you. And helping pioneer the web Repl will put you in a good position to be a key team member once this all takes off...
...which it will, someday...assuming I live long enough and don't get hit by a bus... 
2 Likes
Right what happens with the build executables? Are the most recent ones downloadable so nobody actually has to build them, unless they make changes in the sources to experiment / develop new features.
Running in the web/browser is not my cup of tea and certainly given the quirks of FireFox lately with mouseovers over links not even showing the links, and when reporting FF devs go "it is open source, you can fix it yourself" this feeling does nothing good to that. I feel much more like I need a tool in my toolbox and I want the tool to be on my platform of choice, not on the browser on the platform of my choice, if I wanted a tool on the browser platform perhaps I would already have gone with one of the alternatives.
My view is, the tool is available just on the platform (Windows and a Posix) and supporting it on the browser is good for the cases the platform itself is a more exotic one or to be used to prevent users from installing a thing. I should say I see users and developers as two categories, the second is a species that will be in danger of extinction because everything will be shielded off. It is also why I feel the need for a tool on the platform itself.
Long time ago I tried building on Ubuntu myself, to find that something happened with the blanks! in the script not being accepted anymore. I should try to build again, hope I find the time to do so soon, unfortunately my time is always fragmented into tiny chunks, and hope this has been fixed in the meantime.
Sure I know you cannot be bothered by me not being able to build REN-C. But if I can't chances are others also cannot build it. Which is good when "we" do not want too much activity in "our" world. Such a situation I would classify as unfortunate.
1 Like
I'm regularly building on Ubuntu and it works like charm. You may need the correct r3 executable for the make process, though.
Being able to download the binaries which are built anyway would be good. It might lead to some additional testing, and yes, these are debug builds and not optimized for speed.
It's not like we would expect a run on ren-c, just because binaries are downloadable.
2 Likes
LoL!
I had some "fun" with github/git tonight that has cost me my time and energy to update my repo's and resulting in a merge mess of differences between HEAD and index and no clue as to which is which and smartgit not telling and not letting me select which version to pick over the other, and finally resulting in a failed build because it was the gtk branch that was probably suffering from a wrongly chosen update. But then again I have no idea what I have done, cause I had a proper script, sequence of instructions, to do my update but git wanted my password and then said "no more passwords accepted for updates". So completely lost again. My solution probably will be to go uninstall git and reinstall, if I could I would probably uninstall github itself 
Well, git-hell.
If I run into problems updating a repo,I normally just delete it, and then clone anew.
Of course hoping I have not made any changes in said repo, which normally holds true.
Thanks Ingo,
Yes, the odd thing here is how are you supposed to work from the command line if passwords are no longer accepted and my 2FA is not invoked?
Now I had to accept a complete stranger website that happened to be home of a git gui client with my credentials to github, which personally I consider a HUGE LARGER security risk over a well chosen password.
That is because there were some changes to the bootstrap to make the older executable act more like the newer executable. You'd written some extension configuration based on old build system files that needed to be updated.
I did those changes in July. And as I mentioned at the time, what was left was a linker error in the automated build related to GTK. I said that was something you would need to research.
So resolving the linker error would have been a good thing to tackle before merging more things that would restart the situation again of needing me to sync it up.
In fact, the particular blank behavior may even wind up being undone, due to new considerations. :-/
I generally do not use merging, but I rebase instead. This allows you to play back each commit one at a time, and resolve the differences at every step.
If you're merging with 1000 commits--and things are added and removed at each intermediate point which conflict with your changes--then that may sound laborious. You might find yourself resolving against things that ultimately get deleted, so it could seem like you wasted time. It could seem that merging the final states together is less work.
But in practice, all those 1000 commits wouldn't conflict. Just some of them--and I think it's much more sane and educational to resolve the individual commits "as they happen" and make sure you can get a working build each time.
However this requires understanding how to rebase and to have a really comfortable feeling with how branching and staging and "HEAD" and all of those other things work.
These mechanisms do keep changing and evolving.
You can generate a personal access token and use it like a password, but it's not something you get to type and remember... so you have to copy/paste it from some local file you keep... and it expires so you have to keep regenerating it.
It's valid to be frustrated at technology and how the world is. But... y'know, sometimes you just have to commit yourself to raising your level of understanding. Git is one of those things where the payoff to mastering it is high. And it's also a real liability in the software industry to not be fluent.
I go between SmartGit and the command line, and I'm sure that some 1-on-1 screencast tutoring of seeing my workflow for things would be informative for you...but...I'm busy these days. Maybe there's some kind of online git school that gives you puzzles to sort out, and then shows the kinds of ways to solve them?
https://learngitbranching.js.org/
GitHub - git-game/git-game: terminal game to test git skills
I'm bothered by a lot of things, but people not being able to build it isn't really that high on the list. People familiar with what it takes to build interpreters and compilers would not find it that odd.
I think systems development seems to annoy you more than intrigue you. It requires a certain kind of patience and willingness to go deep in the mastery of things. And I can speak to the fact that much of it has gotten more annoying... and the only thing that shines a light on it is stuff that you would probably not enjoy either (e.g. modern C++, Haskell, Rust...)
1 Like
Well I told you that my time to work on hobby projects like this is very limited, even when I think I can spend over an hour, it will be likely that some interruption will occur within the next 5 minutes, dragging me away.
Even a git workflow apparently changes over time and given the intervals between when I need to use this, keeping up with that is not worth the trouble and certainly not something I will remember how to do.
Well let's say that I do want to spend my time on the real matters, not on the gits, githubs, and other obstacle courses to get to it.
AH, time's up, gotta run! cu later!
1 Like