How do I use waf to build a shared library?

Question

I want to build a shared library using waf as it looks much easier and less cluttered than GNU autotools.

I actually have several questions so far related to the wscript I've started to write:

VERSION='0.0.1'
APPNAME='libmylib'

srcdir = '.'
blddir = 'build'

def set_options(opt):
 opt.tool_options('compiler_cc')
 pass

def configure(conf):
 conf.check_tool('compiler_cc')
 conf.env.append_value('CCFLAGS', '-std=gnu99 -Wall -pedantic -ggdb')

def build(bld):
 bld.new_task_gen(
  features = 'cc cshlib',
  source = '*.c',
  target='libmylib')

The line containing source = '*.c' does not work. Must I specify each and every .c file instead of using a wildcard?

How can I enable a debug build for example (currently the wscript is using the debug builds CFLAGS, but I want to make this optional for the end user).

It is planned for the library sources to be within a sub directory, and programs that use the lib each in their own sub directories.

Churr

After asking this question I also asked: #1596779 Which has lead me to investigate premake.sf.net – Churr

Answer 1

Assuming you are using the latest version of waf (1.5.9 at the time of writing), wild cards can be specified via the glob() method on the build context. So you can write the following:

bld.new_task_gen(
    features = 'cc cshlib',
    source = bld.glob('*.c'),
    target='mylib')

If you were using an older version of waf that doesn't have glob, then there is a method find_sources_in_dirs that you can use:

lib = bld.new_task_gen(
    features = 'cc cshlib',
    target = 'mylib')
lib.find_sources_in_dirs('.')

This method is still in Waf but is slated for deprecation and may eventually disappear.

The srcdir and blddir variables are optional now so you don't need them - they default to "." and "build" anyway. You shouldn't prepend "lib" to the target name, this is done automatically in a platform specific way (on Windows no lib is added and shared libraries use .dll). Debug vs Release build is a surprisingly thorny issue. Originally Waf included this feature, but it was dropped at some point and never re-added. It's a common request on the mailing list so may resurface in the future. Meanwhile you could do a lot worse than use gjc's cflags module. Just add it to your project directory. The final wscript would then be:

VERSION='0.0.1'
APPNAME='mylib'

def set_options(opt):
    opt.tool_options('compiler_cc')
    opt.tool_options('cflags', tooldir='.')

def configure(conf):
    conf.check_tool('compiler_cc')
    conf.check_tool('cflags', tooldir='.')

def build(bld):
    bld.new_task_gen(
        features = 'cc cshlib',
        source = bld.glob('*.c'),
        target=APPNAME)

And to set up a debug build you would run the following:

./waf configure -d debug

If you are using libraries in their own sub-directories, then you should probably have a top level wscript and use the bld.add_subdirs() technique to add library/program directories. Each sub-directory would have its own wscript_build file. You can then use the export_incdirs and uselib_local properties to specify the correct include directories between library and program "modules".

Hoatzin

Although I've not used it, another waf module that might be useful is autowaf.py: svn.drobilla.net/lad/trunk/autowaf.py "Waf utilities for easily building standard unixey packages/libraries" it's GNU GPL v2 or later by Dave Robillard and Nedko Arnaudov – Churr

Answer 2

waf has changed a lot over the years so neither the code in the question nor the answer works with current waf anymore. Nowadays you just write:

def options(ctx):
    ctx.load('compiler_c')
def configure(ctx):
    ctx.load('compiler_c')
def build(ctx):
    ctx.shlib(source = ctx.path.ant_glob('src/*.c'),
              target = 'name')

Note that waf will automatically add the lib prefix so you don't write target = 'libname'. On Windows, you also have to add the defs keyword argument to the shlib function call.

Personally I would recommend against recursive build scripts involving wscript_build files. Not that it doesn't work (like recursive makefiles), it's just much simpler to keep all logic in one medium-sized build script.

Howard