How To Create Web for Inweb Itself

Greetings all. I’ve got inweb installed but one thing I realized is I have no idea how to actually build the web for it. And I don’t see this documented anywhere.

For example, I can do this:

inweb/Tangled/inweb inweb -weave

And that does weave some bits but indicates references it can’t find. I see that the foundation directories also have Contents.w files, so I try this:

inweb/Tangled/inweb inweb/foundation-module -weave
inweb/Tangled/inweb inweb/foundation-test -weave

Those also work up to a point but indicate a whole bunch of references that can’t be found. Each example also has a Contents.w file, but again, it’s not clear at all (at least to me!) what to do in terms of how to generate inweb’s own web.

There are instructions for rebuilding inweb here: https://github.com/ganelson/inweb#build-instructions

I have built it. But what I’m saying is that it doesn’t generate a Woven directory. Are you saying it should be as part of the building process? If you mean to run the makefile that gets generated, all I ever get with that is:

make: Nothing to be done for 'all'.

But that’s only for rebuilding if you’ve changed the source. At least as I understand it.

For the references to work out, I think you’ll need to specify the “colony” of webs to weave:

inweb/Tangled/inweb -colony inweb/colony.txt -member inweb -weave

(But I’ve never really tried this myself.)

1 Like

Yep, indeed. That does seem to work. Much thanks!

As a note, you apparently do need the Inform project available as well. On my one machine, I have inform, intest, and inweb all available and the above command works.

On other machine, I only have intest and inweb and you get:

inweb: fatal error: can't open contents file: inform\docs-src\index.inweb

So that’s good to know. Also on Windows, Norton fires up and blocks inweb.exe based on a Data Protector threat when this is run. Easy to exclude the process, of course, but perhaps worth noting.

You can’t really compile Inform on Windows (in MSYS2 at least), so Mac is going to have to be where I do most of this anyway.

Again, much thanks on the assist!

Ah, I’d misunderstood you. But someone else has given a better answer :slight_smile:

Using MSYS2 is how the Windows releases are built these days, so it definitely does work, with the latest code. If you’re building the Inform 10.1.2 release, possibly not so much.

Ah, good point! So I did check out inform but did not switch to the 10.1 branch. (I did make sure to switch to the stable branches of intest and inweb so this was as a silly oversight on my part.)

On the master branch you get a bunch of errors:

inblorb/Chapter 3/Base64.w:21:1: error: unknown type name 'inchar32_t'
...
inblorb/Chapter 3/Placeholders.w:181:8: error: use of undeclared identifier 'c'

Things of that nature. But on r10.1 there are still errors as well, albeit much further down the chain of operation. What I get are errors like this:

osdepend.c:111:7: error: redefinition of 'glulx_malloc'
  111 | void *glulx_malloc(glui32 len)

osdepend.c:119:7: error: redefinition of 'glulx_realloc'
  119 | void *glulx_realloc(void *ptr, glui32 len)

osdepend.c:125:6: error: redefinition of 'glulx_free'
  125 | void glulx_free(void *ptr)

osdepend.c:132:6: error: redefinition of 'glulx_setrandom'
  132 | void glulx_setrandom(glui32 seed)

osdepend.c:140:8: error: redefinition of 'glulx_random'
  140 | glui32 glulx_random()

It looks like it thinks it’s compiling for a Unix and a Windows maybe? Those functions are defined twice is osdepend.c with #ifdef directives. But the lines in question show:

cc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-unused -DOS_UNIX -I../cheapglk    -c -o main.o main.c

Whereas earlier lines show:

cc -g -Wall    -c -o cgfref.o cgfref.c

Notice no -DOS_UNIX in that second one. So far any lines I see with a problem seem to qualify with -DOS_UNIX, like the first line above. From what little I can see, it looks like -DWIN32 might be the more viable option.

Anyhow, just throwing this out there in case others stumble across this thread and encounter the problem.

Inform and intest are both coupled to inweb, you can’t expect to build the latest inform with an older inweb and vice versa. So I’d suggest you use either the latest version of everything, or the appropriate release branch for everything.

On Windows, the latest code will build with MSYS2, because that’s how I’m building it all the time. For the release branches you would still need Cygwin, or be prepared to figure out the changes needed to make MSYS2 work.

Ah! I got you now. I will give that a shot as we speak. I’ll post an update. But I now better understand the context you were giving that I wasn’t picking up on.

Much thanks for the patience.

UPDATE: Just to close the loop - it works! So the master branch across all three repos fully build in the MSYS2 context. Sweet!

1 Like