Index

Ufy Configuration

Introduction

This document describes how the ufy interpreter finds its way around your system when it starts up, and, conversely, how you can tune the ufy interpreter to behave according to your will on your system. Since this involves files, and since filesystems tend to differ among operating systems, certain sections of this document might not apply to your particular situation.

On UNIX

Before you build

Ufy is distributed as source files, so if you got your hands on a source archive it's good to remember that, before you build it, you can change things about the resulting executable and the way it's installed onto your filesystem.

A 'configure' script is issued with the ufy source archive, which you can run to specify what things you want tuned when you compile the ufy interpreter. The 'configure' script has the following command line options:

--cc=CC
--develop
--without-symlinks
--without-threads
--without-network
--mini
--debug
--nodl
--static
--lockpoolsize=N
--prefix=PREFIX
--bindir=BINDIR
--modulesdir=MODULESDIR
--packdir=PACKDIR
--coredir=PACKDIR
--docdir=DOCDIR
--libdir=LIBDIR
--includedir=INCLUDEDIR
--config=UFYCONF
--userhomeinstall
--with-oracle=ORACLE_HOME
--with-pgdb=PATH
--with-tds=PATH
--with-mysql=PATH
--with-db3=PATH
--with-curses=PATH
--with-gtk=PATH

Configuration files

The ufy executable allows you to specify a configuration file as a command line argument. The '-c' option does that for you. If, however, you do not specify a configuration file to use to the ufy interpreter, it will try to find it automatically. On UNIX, the configuration file is called 'ufyconf.ufy' or '.ufyconf.ufy' and it will be searched for in the following locations:

Tuning

The configuration file is loaded and prefixed to every ufy script executed by the interpreter. This can be done because the ufy config file is written in ufy itself and consists, in a regular setup, only of directives that tell the interpreter where to look for things and how to see its module namespace. Newly installed native modules, for example, have in it a place for entering their whereabouts and how they want to be known to the interpreter.

Because the configuration file is written in ufy itself, then once you know the languague, it's quite easy to change your setup. Take a regular ufy configuration file, for example, that looks like this:

#use $lang
#require $lang
#module pack type=dir recursive=true path=/usr/local/ufy/pack
#module core type=dir recursive=true path=/usr/local/ufy/core
#module native type=dir path=/usr/local/ufy/modules recursive=false
#alias types core/types
#alias stdio core/stdio
#alias string core/string
#alias stdlib core/stdlib
#alias time core/time
#alias net core/net
#alias std stdio string stdlib time net types
#path /usr/local/ufy/pack
Suppose you'd want to change what it means to '#use std'. Of course this is not common sensical, because many ufy programs depend on its current meaning, but suppose you'd want to change it nonetheless.

still to write..

Suppose you have written a module to add functionality to ufy in C. But before you release it to the world with all of its proper installation kit, you want to test the thing over and over again, of course. As well you should. A simple addition to the ufy configuration file is all it takes to test the waters of the installation and to make sure you won't have to type in any more letters to use the module from your scripts:

#module foo type=native path=/home/joe/work/ufymodules/mymodule.so
And presto - all you have to do now from your code is issue a '#use foo' and you're good to go.

On Windows

still to write..


Author: Kees Jan Hermans
Date: 2006-07-06