How does SCI Studio or SCI Companion compile?

[Cryptonomic]

Here

[Omni]

I see the circular reference and not sure why it is the way it is. Others here can answer that better then me hopefully. I do know 1.4 was the most recent version. It also appears to be the win32 version is that correct? If so here is the 1.4 I believe

http://youpointwebash.com/WIN32/sccw32.exe.

If you do not like compiled .exes you can compile it from his vga source code release under Borland.

Now I have not tested that compile I do know the program opens but I do not currently have time to throw anything at it, and it may be a special version that has static uh not sure of the proper phrase, maybe its lookups?.

[Nostalgic]

Check out my thread from the past:

http://sciprogramming.com/community/index.php/topic,207.0.html

What you're running into is what I ran into: SCI is horribly documented in many ways, in terms of its supporting tools. A sad state of affairs. You actually seem to have persisted a bit more than I did, however.

My guess is that what might be happening is that the tools are doing some sort of precompile step in a stepwise fashion. So essentially you have scripts with the "use" statements commented out or something. Then you compile the standalone scripts in the first pass to get the sco file. Then the second pass of the compilation process puts the "use" statements back in. I do agree with you, however, that it seems really odd how the files circularly depend on each other. That's why I believe there must be a mechanic that does multiple passes for compiling.

The other thing you might notice is that when you use the scc compiler, you have to have all the files in the same directory. But in actual SCI templates, the source is in an src directory. The resources are not in that directory but rather in the parent. And some included header files are not even in those directories at all.

[gumby]

This reminds me of compiling C programs - first you 'compile' then you 'link' in the external dependencies.  Is it possible to kick off the scc command for all files in the directory simultaneously (like scc.exe <all>)?

[Cryptonomic]

This reminds me of compiling C programs - first you 'compile' then you 'link' in the external dependencies.  Is it possible to kick off the scc command for all files in the directory simultaneously (like scc.exe <all>)?

As far as I can tell, no. There is no help listing or list of switches that you can discern. If you just type in scc.exe, you get this:

Code: [Select]

Useage:
SCC [input.sc] [gamedirectory]

If you try something like scc.exe *.sc, it doesn't work.
If you try to include more than one file to compile, it doesn't work.

I did try to use the sccw32.exe version. (Note: if anyone tries this, you need to have the cc3250.dll in the same directory or it won't work.) That version, however, appears to be hard coded to look in certain paths and for certain files. Specifically, it seems to look in G:\scigames\vgadev\src\ for a series of files.

I agree that it does sound like there are two steps: a form of compiling and linking. The trick is that I don't even see how the compiling can happen unless Nostalgic is correct in that there is some sort of backpass mechanism. If that's the case, clearly the scc.exe is not really a standalone compiler.

I did look at the Compile.cpp file that is in the SCI Companion source release but I'm not as familiar with C++ so it's bit slow going for me. I think the CompileContext.cpp file seems to indicate some of what is going on behind the scenes. The code is well commented but it's more about implementation than intent so I can't quite get the full gist of what's happening.

[gumby]

So I ran into the identical problem in Studio today.  I didn't use the 'Compile All Scripts' option - I was compiling script-by-script.  The only way to resolve it was to comment out the dependencies in one script & compile it, compile the second script, then uncomment the dependencies in the first script & compile.

[gumby]

Encountered the same problem in Companion.  Doesn't matter if you try to use the 'Compile All' option either.

I'm wondering if I could just create the exact same scripts, but stripped way down to the point where it is simply a prototype (analogous with function prototypes in C), compile them all then replace the prototype scripts with the actual scripts.  Maybe that would allow me to get around the circular dependencies.

[gumby]

Verified.  This works just fine.  For a test, I created two script files, without cross-dependent 'use' statements.  The scripts were identical to this (notice the commented out cross-dependencies)

Code: [Select]

(include "sci.sh")
(script 526)
//use ("PrintCont")
(procedure public (DescribeOb))


Code: [Select]

(include "sci.sh")
(script 528)
//use ("DescribeOb")
(procedure public (PrintCont))

Then I 'Compiled All' which worked just fine.  Then went about putting the real code into the each procedure, re-introducing the cross-dependencies between the scripts.  'Compile All' again and everything worked.

This makes sense.  When the compiler attempts to compile a script, it ensures that a compiled (sco) version of each 'use' script exists.

[Collector]

What are you using to compile it?

[gumby]

I'm using Companion to compile it. 

I'm now looking into using the scc.exe compiler for the stripped-down 'dummy' scripts.  I was thinking about throwing together a Perl script that would parse out the game.ini file, getting all the script references.  Then I can generate a dummy script for each one and compile it with scc - then copy the resulting *.sco files into the src directory of my game.

Then I can go into Companion & do a 'Compile All' and not have any problems with cross-dependencies.

[gumby]

Okay, I've created a Perl script to solve this problem.  I doubt anyone will have a use for it except for me, but I've uploaded it for completeness anyway.

I did end up using the SCI Script Compiler 1.33 - so if you want to use this script, you'll need to get a copy of it.

[Collector]

Did you make a Wiki entry?

[gumby]

There is now.  If anyone downloads & uses the tool, I'd love to know why 

[Collector]

You never know when something might be useful.

[gumby]

Blast it.  I find myself back at the original question of this thread - what are steps of compilation?

.SCO files - What are the purpose of these files?  At first, I thought that these were stand-alone, compiled scripts.  However, upon opening them they just contain a reference to each 'global' symbol in the script.  If a script has 3 procedures in it, there will be the three procedure names in the SCO - global variables are also placed in the SCO.  It's almost as if these are just 'prototypes' of the script itself, perhaps to satisfy compilation of other scripts.

When a script is compiled within Studio or Companion, it generates the SCO, but then it also modifies the resource.map & resource.001 file.  The .map file is like an index into the resource file (as I recall), and the resource file contains the actual compiled code.

What was the original purpose of the scc.exe tool?  What good is just generating an SCO?  Why doesn't it as part of it's steps modify a resource.map & resource.001 file?  If it is a compiler - where is the outputted compiled code?

When a 'Compile All' is performed within Studio, it seems to take inventory of all the scripts that are already compiled into the resource.map/resource.001 file (this inventory step may occur upon opening of the game?).  Only scripts found from this 'inventory' step are compiled.

When a 'Compile 'All' is performed within Companion, it does not behave like Studio.  I suspect it gets a list of scripts to compile from the game.ini.

My frustration now is the inability to use either Studio or Companion to compile my project, which consists of a large number of scripts needing compilation, that are introduced externally from the Studio/Companion environment.  Companion gathers up the scripts to compile from game.ini (which contain references to all my scripts) - but crashes on a 'Compile All' because of my large number of scripts - at least that seems to be why it crashes.  Studio doesn't have a problem with the number of scripts, but won't compile my scripts because it can't find them in the resource.map/resource.ini files.

I suppose the next logical step is to inject dummy compiled scripts into the resource files so that a 'compile all' will work within Studio.