views:

628

answers:

3

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.

A: 

Agh, it is all over the place: check this out http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

vehomzzz
That's not helpful in the context of waf.
James Morris
why do you use waf? just curious, as it is a not portable utility, with a presumptuous promise of ease. I would go with an 'l fashion way, if you can...
vehomzzz
Good question! I don't use it. So you're saying I should go back to just writing a plain old hand-crafted Makefile?
James Morris
+1  A: 

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".

rq
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
James Morris
Handy that one, thanks.
rq
A: 

I wonder, why Andrei states that waf is not portable. It runs on python, and does not depend on much extra python libs than what is in the base python distribution. Also, in constrast to a make-based environment, it does not depend on a shell or shell tools, which we know, are not really well working in all environments. I'm really no fan of writing makefiles working for linux and windows, considering the difference of a *sh or cmd.exe and the available tools. And running a msys or even cygwin, most of the time just creates more problems than it helps. waf on the other side already provides a good OS abstraction, and can even handle OS specific file/dir-names (separators), and you have a scripting language at hand. When I look at our old-style build environment based on a local cygwin+gnu-tools, perl, sed, awk, etc. and the mess of the makefiles and perl scripts, i really prefer a build tool like waf.

none