The library provides two ways for deploying applications: either using the FastCGI protocol, in conjunction with a webserver (like apache), or using a built-in web server (wthttpd). You only need one of these, but you can have both of them.
The built-in web server is more convenient during development and is easier to setup.
The FastCGI based solution provides more flexibility for deployment of the application. The built-in web server runs all sessions in a single process, while the FastCGI based solution allows different deployment schemes including dedicated processes per sessions.
Each of these two choices correspond to a library, a so-called connectory library. Below it is outlined how to configure the build process of Wt to build either or both libraries (libwthttp and libfcgi).
Thus, to build a Wt library with built-in web server you need to link against libwt and libwthttp. To build a Wt library which acts as a FastCGI process, you need to link against libwt and libfcgi.
When using FastCGI, Wt requires a webserver (like apache, lighttpd or nginx) which supports the FastCGI protocol.
Given that Apache is still the most popular webserver, below are the requirements for apache, for other web servers the list is similar:
The recommended way to build the library is in a seperate build directory, for example within the top-level of the Wt package:
$ cd wt-x.xx
$ mkdir build
$ cd build
$ cmake ../
The latter command will try to locate the necessary libraries. If everything is OK, then this should end with something like:
-- Generating done -- Build files have been written to: /home/kdforc0/project/wt/build
To build a multi-threaded version of Wt, which uses multiple threads for handling concurrent requests, you need a thread-enabled boost library. By default, CMake 2.6 will only search for a thread-enabled boost installation, while CMake 2.4 will fall-back to a non-multithreaded boost library, reporting:
... -- Looking for pthread_create in pthread - found ** Disabling multi threading. ...
Most linux distributions provide multi-threaded boost libraries by default now.
If CMake fails, because it cannot resolve all dependencies, then you may help CMake by setting some variables to help CMake locate the libraries. This may be done on the command-line using -Dvar=value or using the interactive program:
$ ccmake .
Variables that you may set to configure Wt's built-in boost finding method:
$ make
$ make install
If you did not install Wt in a directory (CMAKE_INSTALL_PREFIX) included in the default linker dynamic library search path, then the web server will not be able to start Wt programs (such as the examples).
Fix it by (as user with sufficient permissions):
$ ln -s /your/path/to/lib/libwt.so /usr/lib
$ ln -s /your/path/to/lib/libwtfcgi.so /usr/lib
Deploying an application is different when using FastCGI or the built-in web server (wthttpd).
The examples that come with the library use the connector specified by the build option EXAMPLES_CONNECTOR (see supra).
Some examples need third-party JavaScript libraries (ExtJS or TinyMCE).
$ make -C examples
$ cd examples/X
$ ./deploy.sh
Treat the example as a mod_fastcgi application, by adding a line to 20_mod_fastcgi.conf in your Apache configuration modules.d/ directory, e.g.:
FastCgiServer /var/www/localhost/htdocs/wt-examples/composer/composer.wt
$ make -C examples
Most examples use additional files, such as message resource bundles, which are not indicated with absolute path names. Therefore the working directory should be the source directory for the example (unless you use the ./deploy.sh script to deploy everything in a dedicated deployment directory). A similar argument goes for icons and the setting of the --docroot variable.
$ cd ../examples/X # source directory for example X
$ ln -s ../../resources . # include standard Wt resource files
$ ../../build/examples/X/X.wt --docroot . --http-address 0.0.0.0 --http-port 8080
This will start a httpd server listening on all local interfaces, on port 8080, and you may browse the example at http://127.0.0.1:8080/
To make sure the web server has all auxiliary files (like images, CSS style sheets, and perhaps other things) in place for the web application, you could use the ./deploy.sh script to copy everything into a directory (see the cmake DEPLOYROOT variable)
You will notice 404 File not Found errors for resources/ files if you are missing the resources files.
These are all the command-line options that are available:
General options:
-h [ --help ] produce help message
-t [ --threads ] arg (=10) number of threads
--servername arg (=vierwerf) servername (IP address or DNS name)
--docroot arg document root for static files
--errroot arg root for error pages
--accesslog arg access log file (defaults to stdout)
--no-compression do not compress dynamic text/html and text/plain
responses
--deploy-path arg (=/) location for deployment
--session-id-prefix arg prefix for session-id's (overrides wt_config.xml
setting)
-p [ --pid-file ] arg path to pid file (optional)
-c [ --config ] arg location of wt_config.xml. If unspecified,
WT_CONFIG_XML is searched in the environment, if
it does not exist then the compiled-in default
(/etc/wt/wt_config.xml) is tried. If the default
does not exist, we revert to default values for
all parameters.
HTTP server options:
--http-address arg IPv4 (e.g. 0.0.0.0) or IPv6 Address (e.g. 0::0)
--http-port arg (=80) HTTP port (e.g. 80)
HTTPS server options:
--https-address arg IPv4 (e.g. 0.0.0.0) or IPv6 Address (e.g. 0::0)
--https-port arg (=443) HTTPS port (e.g. 443)
--ssl-certificate arg SSL server certificate chain file
e.g. "/etc/ssl/certs/vsign1.pem"
--ssl-private-key arg SSL server private key file
e.g. "/etc/ssl/private/company.pem"
--ssl-tmp-dh arg File for temporary Diffie-Hellman parameters
e.g. "/etc/ssl/dh512.pem"