Skip to content
Commits on Jul 7, 2014
  1. @capflam

    Massive autotools refactoring & cleanup

    capflam committed Jun 10, 2014
    Now, all makefile are generated by automake. This way, many things are more
    configurable and maintainable.
    
    Main (visible) changes:
    
     * Now, you can configure and compile Yaws outside the source directory. It is
       also possible to generate an archive for distribution, using the 'dist' target
       (from now, 'distcheck' target should always pass).
    
     * We track .erl dependencies using '-M*' flags of ERLC.
    
     * generated header 'yaws_configure.hrl' disappears. HAVE_SENDFILE,
       HAVE_ERLANG_SENDFILE and HAVE_CRYPTO_HASH macros are defined in ERLC flags.
    
     * yaws_generated:localinstall/0 function disappears (see comment about local
       install).
    
     * To create a windows installer, we just need to run the 'mkinstaller'
       target. Read win32/README.developer for details.
    
     * We use standard Erlang installation path for Yaws, relative to the erlang
       library directory (/usr/lib/erlang/lib). Now, '$(libdir)/yaws' is a link. We
       do the same for yapp application.
    
     * "local install" was removed. Now, to do a "developer install", we just need
       to set a prefix during the project configuration using --prefix option. So,
       you need to install yaws to test it.
    
     * DESTDIR variable is still supported.
    
     * scripts/make-release was rewritten to use 'dist' and 'mkinstaller' targets.
    
     * Installation of Yaws applications has slightly changed. Now they are
       installed in their own directory, in '$(localstatedir)/yaws'. So, chat
       application will be installed in '$(localstatedir)/yaws/chat', with 'www' and
       'ebin' subdirs.
    
    Main targets (others than all/install/clean....):
    
      * all           : compile Yaws
      * debug         : compile Yaws with debug flags
      * clean         : remove files produced by all or debug target
      * install       : do a proper install of Yaws
      * doc or docs   : build the documentation
      * check or test : launch tests
      * cleantest     : remove files produced by check target
      * dialyzer      : run dialyzer on Yaws
      * mkinstaller   : build an installer for windows
      * cleaninstaller: remove files produced by mkinstaller target
      * apps          : compile Yaws applications (chat,mail,wiki,yapp)
      * cleanapps     : remove files produced by apps target
      * installapps   : install Yaws applications
      * fullinstall   : install + installapps
      * fullclean     : clean + cleantest + cleanapps + cleaninstaller
    
      To install an application, run: (cd application/{APP} && make install)
    
    Of course, many things can be customized during configuration and Rebar still
    works as expected. To do an install with (almost) the same tree than with
    previous of Yaws, do:
    
      $> ./configure yawsdir=${prefix}/lib/yaws yappdir=${prefix}/lib/yapp \
            --sysconfdir=/etc --localstatedir=/var
      $> make install
    
    Here is the default installation tree on my debian:
    
       usr
        ├── lib
        │   └── erlang
        │       └── lib
        │           ├── yapp-0.4.2
        │           │   ├── doc/
        │           │   ├── ebin/
        │           │   ├── examples/
        │           │   └── priv/docroot/
        │           └── yaws-1.98
        │               ├── ebin/
        │               ├── include/
        │               └── priv/
        │               ├── examples/
        │
        ├── local/bin/yaws
        │
        ├── local/etc/init.d/yaws
        ├── local/etc/yaws/
        ├── local/etc/mail/yaws-webmail.conf
        │
        ├── local/lib/pkgconfig/yaws.pc
        ├── local/lib/yapp -> /usr/lib/erlang/lib/yapp-0.4.2
        ├── local/lib/yaws -> /usr/lib/erlang/lib/yaws-1.98
        │
        ├── local/share/doc/yaws/yaws.pdf
        ├── local/share/man/{man1,man5}/
        │
        ├── local/var/log/yaws
        ├── local/var/run/yaws
        └── local/var/yaws
            ├── chat/{ebin,www}
            ├── mail/{ebin,www}
            ├── wiki/{ebin,www}
            └── www
Commits on Apr 13, 2014
  1. @vinoski
Commits on Nov 29, 2012
  1. @capflam

    Fix compilation of mime_types.erl when working directory is not 'yaws'

    capflam committed Nov 29, 2012
    When mime_types.erl is generated, we must check if it is done during a Yaws
    compilation or a Yaws startup. In the first case, we must use a relative
    path for includes. Else include_lib must be used.
    This issue was reported by Andrei Zavada and avoid a compile error when the
    working directory is not 'yaws'.
    
    The mechanisms to generate and compile this file have also changed.
    
    Then, to centralize calls to yaws_generated:is_local_install/0, following
    functions was added in yaws.erl:
      get_app_dir/0, get_src_dir/0, get_ebin_dir/0, get_priv_dir/0, get_inc_dir/0
Commits on Sep 1, 2012
  1. @vinoski

    update mime.types file

    vinoski committed Sep 1, 2012
Commits on Jul 25, 2012
  1. @capflam

    Make the mime types mappings configurable

    capflam committed with capflam Jul 19, 2012
    Now, it possible to customize the global mime types mappings and to overload
    it for each virtual server. It can be done using following directives in the
    global part or the server part of the configuration:
    
    * default_type: Defines the default mime type to be used where Yaws cannot
      determine it by its mime types mappings (default: text/plain).
      In the server part, this directive overloads the global one.
    
    * default_charset: Defines the default charset to be added when a response
      content-type is text/* (default: none). In the server part, this directive
      overloads the global one.
    
    * mime_types_file: Overrides the default mime.types file included with Yaws
      (default: ${PREFIX}/lib/yaws/priv/mime.types). In the server part, this
      directive overloads the global one but mappings defined in this file will
      not overload those defined by add_types directives in the global part.
    
    * add_types: Specifies one or more mappings between mime types and file
      extensions. More than one extension can be assigned to a mime type. If a
      mapping is defined in the global part and redefined in a server part using
      this directive, then the later is used. Else the global one is kept.
    
    * add_charsets: Specifies one or more mappings between charsets and file
      extensions. More than one extension can be assigned to a charset. If a
      mapping is defined in the global part and redefined in a server part using
      this directive, then the later is used. Else the global one is kept.
    
    Here is an example:
    
      default_type = text/html
    
      <server localhost>
          port = 8000
          listen = 0.0.0.0
          docroot = /var/www
          # nothing is overloaded in the vhost
      </server>
    
      <server localhost>
          port = 8001
          listen = 0.0.0.0
          docroot = /var/www
    
          # overload global configuration:
          default_type    = text/plain
          mime_types_file = /etc/mime.types
          add_types       = <text/xhtml, yaws> <application/x-test, tst test>
          default_charset = UTF-8
          add_charsets    = <ISO-8859-1, php html yaws> <US-ASCII, tst>
      </server>
    
    During Yaws compilation, a default module 'mime_types' is created using the
    default mime.types file. Then, when yaws starts up, this module is
    re-generated, re-compiled and loaded dynamically. The new module replaces the
    default one but the .beam file is unchanged. So if one of these steps failed,
    we fall back on the default module.
Commits on Mar 17, 2012
  1. @kalski @vinoski

    added soap12 capability

    kalski committed with vinoski Mar 9, 2012
Commits on Oct 31, 2011
  1. @vinoski

    whitespace cleanup

    vinoski committed Oct 31, 2011
    Remove all trailing whitespace from all text files. Some bot sent
    Klacke and me a pull request saying it had done this for us, but I
    reviewed the diffs and it was affecting lines that shouldn't have been
    affected, so perl and I did it ourselves instead.
Commits on Feb 23, 2009
  1. empty dir

    committed Feb 23, 2009
Commits on Dec 10, 2006
  1. Adding SOAP processing capabilities to Yaws.

    Tobbe Tornquist committed Dec 10, 2006
    Read the www/soap_intro.yaws for more info.
    
    
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@1044 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Feb 11, 2002
  1. Initial revision

    committed Feb 11, 2002
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@2 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Something went wrong with that request. Please try again.