Ladislav may have a different suggestion, but I've found that having build scripts works well for application oriented scripts, those that need to be encapped for deployment. For scripts that don't need to be encapped, I use INCLUDE directly, as you do above.
Though I use DO, not #INCLUDE in the latter case.
My build scripts also set a deployment target type that controls conditional includes and logic where needed. e.g., desktop vs rich 'net app vs plugin.
DocKimbel
Gregg: good point about DO, it should be rather:
REBOL [ ]
do %include.r ;-- when run with DO #include %include.r ;-- when passed to Encap include %lib/a.r include %lib/b.r
app: context [...] app/run
Damn, no, `do %include.r` should be conditional, and disabled when encapping...
Ladislav
I use this form frequently:
REBOL [ file: %myscript.r ]
#include %lib/a.r #include %lib/b.r
app: context [...] app/run
and evaluate it as follows:
include %myscript.r
also, this form is directly encappable
DocKimbel
The include system I use for all my apps that need to be encapped allows me to do this: # rebol -s %cheyenne.r and # encap %cheyenne.r
Can INCLUDE provide similar feature? If yes, how can it be achieved in the easiest way? If not, what is the closest option INCLUDE can provide me?
Ladislav
Yes, that is very similar to what I use here
DocKimbel
Ladislav: in your above form, how do you deal with READ calls (for reading data files) in the application?
Ladislav
reading data files in the application? - you mean to be "in the application"?
(when encapped?)
DocKimbel
Both cases, when run and encapped.
Ladislav
yes, it is always both
DocKimbel
I mean, when encapped, such data file should be encapped too.
Ladislav
I can use either #include-binary or #include-string, etc. directives, or even the #do directive for something different
DocKimbel
When run with DO, it should be just read from disk.