bug#11204: automake-1.11.4 test failures, powerpc-darwin8
This looks suspicious: FAIL: distcheck-override-infodir.test (exit: 2) === distcheck-override-infodir: running install-info --version Debian install-info 1.10.21. Copyright (C) 1994,1995 Ian Jackson. This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO warranty. Why do you have Debian install-info installed on Mac OS X? It is not used anymore even on Debian: $ cat /etc/debian_version wheezy/sid $ install-info --version This is not dpkg install-info anymore, but GNU install-info See the man page for ginstall-info for command line arguments install-info (GNU texinfo) 4.13 and in fact Automake has stopped trying to cater to Debian install-info since the release 1.11.2. What happens if you re-run the failed tests after defining 'AM_UPDATE_INFO_DIR' to "no" in the environment? Like this: $ cd tests && AM_UPDATE_INFO_DIR=no make -jN recheck So I have an install-info from dpkg, which is used by fink, which installs packages to another prefix (default: /sw): fang% which install-info /sw/sbin/install-info fang% dpkg -S `which install-info` dpkg: /sw/sbin/install-info % env AM_UPDATE_INFO_DIR=no make recheck FAIL: install-info-dir.test FAIL: distcheck-override-infodir.test PASS: instfail-info.test PASS: txinfo3.test PASS: txinfo13.test PASS: txinfo16.test PASS: txinfo18.test PASS: txinfo19.test PASS: txinfo22.test PASS: txinfo23.test PASS: txinfo24.test PASS: txinfo26.test PASS: txinfo25.test PASS: txinfo28.test PASS: version7.test PASS: txinfo33.test PASS: vtexi4.test = 2 of 17 tests failed See tests/test-suite.log Please report to bug-autom...@gnu.org = make[1]: *** [test-suite.log] Error 1 make: *** [recheck] Error 2 Log file attached. Fang -- David Fang http://www.csl.cornell.edu/~fang/ automake-1.11.4-powerpc-darwin8-recheck.log.bz2 Description: BZip2 compressed data
Re: How do I configure Makefile.am to run a program?
Don't use make to do this - just use autoconf, and let your configure script deal with it: configure.ac AC_INIT(...) ... svnrev=`svnversion .` AC_SUBST(svnrev) ... AC_CONFIG_FILES([Makefile ... poll.spec) AC_OUTPUT Now create a file called poll.spec.in that contains an exact copy of your existing poll.spec, but add the autoconf substitution variable, @svnrev@ where it make sense. In a Makefile.am in the directory containing your poll.spec file, add EXTRA_DIST = ... poll.spec I use this trick all the time and it works great! In fact, I generate most of my rpm and debian build scripts this way. Thanks, but the problem with this solution is that I would have to rerun the .configure step each time. Forgetting to do that is as as easy as forgetting to edit the spec file. Hi, Doesn't AC_CONFIG_FILES automatically add regenerations rules to the Makefile? usually resembles something like: # somewhere in Makefile.in config-generated-file: [config-generated-file.in] cd $(top-srcdir) && ./config.status config-generated-file If the command run to generate it is some script (which is used by config.status), you should be able to append a dependency: # to Makefile.am config-generated-file: generating-script Anytime config.status or your generating script changes, it should automatically be regenerated. (And if only your generating script changes (not configure.ac), it won't re-run all of configure, just that output phase, config.status.) And if you want the target to always be up-to-date, add it to BUILT_SOURCES=, or all-local:, as others suggested. I let 'make' take care of any dependencies, basically. HTH, Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
Re: Bison C++ parsers and ylwrap
It probably is a bug. I for one use bison/yacc very sparingly only and
lack the experience how to deal with it portably. Which is why it would
be better if someone else worked on fixing it.
For whatever it's worth, I have always found bison's C++ support to be
sub-par. It's always been easier to create C source from bison, put
some 'extern "C"' decls in the %{ %} header of the .y file, and output
to a .cc file.
So while I have no resolution for the bug, I would encourage you to just
use bison conventionally as a workaround.
Another data point, I use the normal C-skeleton style parsers from
bison/yacc but compile them in C++ (myparser.yy -> myparser.cc), and have
no problems with using C++ in the semantic actions. (I also don't
need any extern "C" declarations/references as long as everything is
compiled consistently as C++. I've been doing this since yacc (skeleton
1.14?) and bison 1.35.
Fang
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
Re: can 'make', can 'make dist', but can't 'make distcheck'
./configure \ --prefix=$HOME/jmf/testes/localroot/usr/ \ CPPFLAGS="-DHPUX -DSUN -DLINUX -I/usr/include/libxml2/ \ -I/home/jmf/tibcu/tibrv/include/" all goes well. make is successfull and builds my libs correctly ! make dist also creates the tar.gz but make distcheck complains. this is my distcheck command: - make distcheck \ CPPFLAGS="-DHPUX -DSUN -DLINUX -I/usr/include/libxml2/ \ -I/home/jmf/tibcu/tibrv/include/" --- You pass configure parameters to distcheck with: make DISTCHECK_CONFIGURE_FLAGS="configure_params..." distcheck Quotes recommended to keep shell from splitting up params. These errors are probably fallout from not finding some headers in those CPPFLAGS paths, I'm guessing. this is how it complaints --- ../../../c/src/IFXDoc.c: In function 'IFXDoc_addNullU64Array': ../../../c/src/IFXDoc.c:10258: warning: this decimal constant is unsigned only in ISO C90 ../../../c/src/IFXDoc.c:10258: warning: integer constant is too large for 'long' type ../../../c/src/IFXDoc.c: In function 'IFXINTERNAL_IFXDoc_xml_addArrayField2XML': ../../../c/src/IFXDoc.c:18747: warning: assignment makes pointer from integer without a cast make[3]: *** [IFXDoc.lo] Error 1 make[3]: Leaving directory `/home/jmf/ifxlib/libifxlib-7.8.9/_build/c/src' make[2]: *** [all-recursive] Error 1 --- just guessing ? could make distcheck be using something like a very demanding, 'no cast warnings allowed' or some '-Werror' compiler flag ? distcheck doesn't add anything to your flags. Sometimes it helps to log distcheck to a file for debugging: $ make distcheck 2>&1 tee distcheck.log HTH. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
duplicate installdirs bug
Hi, With automake 1.9.6, I'm getting distcheck failures during the install phase (or just during non-distcheck make install): = reduced Makefile.am = # let package name == 'yoyodyne' foodir = $(pkgdatadir)/foo foo_DATA = file1 dist_foo_DATA = file2 === - results in (Makefile.in): --- === # note the duplicate am__installdirs = "$(DESTDIR)$(foodir) $(DESTDIR)$(foodir)" ... installdirs-am: for dir in "$(DESTDIR)$(foodir)" "$(DESTDIR)$(foodir)"; do \ test -z "$$dir" || $(mkdir_p) "$$dir"; \ done === which errors out during "make DESTDIR=/tmp/somewhere install" on the second iteration of the for-loop. mkdir: /tmp/somewhere/usr/local/share/yoyodyne/foo: File exists Workaround: if I wrote my DATA files as a single foo_DATA instead of split # equivalent to above foo_DATA = file1 file2 EXTRA_DIST = file2 Then the installdirs will be duplicate-free. Not too much trouble. or fix: hack automake to eliminate repeated dirs in $(am__installdirs) or add a clause after $(mkdir_p) ... || : to make it never fail or ignore exit status of $(mkdir_p)? (not the greatest idea) or add a 'test -d' for directory existence before $(mkdir_p)-ing it? Haven't tested this case against automake-1.10 yet. Thanks for investigating. Fang
Re: autotools on mac os x
> > Could you give me an hand, i have been searching for 2 entire days.. > > Try Fink. > > http://fink.sourceforge.net FWIW, fink has done wonders for my open-source software addiction. :) When being prompted through the configuration process, I recommend enabling the 'unstable' tree which contains several times more packages. After installing and configuring fink, % fink selfupdate (update package descriptions, re-index) % fink install automake1.9 (gets you automake 1.9.6) % fink install libtool14 (gets you GNU libtool 1.5.22) % fink install autoconf (gets you autoconf 2.60) Fang
Re: running tests in parallel
> > It would be nice if it were possible to run tests in parallel using > > automake. Waiting for tests to complete on a 4-way box while they > > are run > > on a single CPU is annoying. As most 'make' implementations already > > support running in parallel (-j), automake could just utilize this > > functionality to runt tests in parallel. > > I very much agree. Hi all, I use a simple recipe for parallelizing tests without any modification to automake, but it may require some semi-automatic dependence tracking to get right. I have the targets listed in the TESTS variable as trivial shell scripts that are the results of other dependencies that actually run the tests. The gist of it: TESTS += my_test.sh ... # process result of test into trivial script my_test.sh: my_test.diff echo "#!/bin/sh" > $@ ; \ if test -s $< ; then \ echo "exit 1" >> $@ ; \ fi ; \ chmod +x $@ # test post-processing my_test.diff: my_test.actual my_test.expect diff -u $(srcdir)/my_test.expect my_test.actual > $@ # here, my_test.expect is expected to reside in the srcdir # running the built executable on some input my_test.actual: (input file, maybe executable too) (some command to make it) The tests are only run with 'make check', but I've added some convenience targets to run the tests without going through make check_TESTS Since I have thousands of tests with some long dependence chains between tests, I use many custom suffix rules and automatically compute additional dependencies where needed. Since most of my tests follow the diff-and-check pattern, I end up having to append dependencies to .diff targets, since I'm not using %-style rules. -include diffs.depend diffs.depend: cat $(list of test files through sed/awk filter) > $@ diffs.depend will look like: test1.diff: test1.expect test2.diff: test2.expect test3.diff: test3.expect while the suffix rule is: .actual.diff: (deduce expect file name from $< and run diff) This procedure sped up my tests by a perfect 2x on all of the dual-processor machines I could get my hands on. I tried make -j4 ... -j32 as an experiment and watched the process tree (pstree) explode, but didn't get much beyond 2x speedup. I highly recommend doing this for any reasonably large test suite. Is this enough to work with, or should I post a more concrete example? Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
Re: Preprocessing C++ only
> SUFFIXES = .i > noinst_DATA = Quadratic.i > .cpp.i: > $(CPP) $(CPPFLAGS) -E -o $@ $< Hi, Sometimes it is useful to distinguish C from C++ preprocessed files, I use .ii for C++ and .i for C. If you want to retain the CFLAGS/CXXFLAGS/CPPFLAGS from configure, then it's convenient to define the rule as: SUFFIXES += .i .ii .c.i: $(COMPILE) -E $< > $@ .cpp.ii: $(CXXCOMPILE) -E $< > $@ since $(COMPILE) and $(CXXCOMPILE) are generated in Makefile.in. I use these frequently when debugging, and usually add these rules to new projects' Makefile.am's. HTH, Fang
Re: autotools not suited to proprietary development?
> I think you're confusing the idea of a build system for portable
> software (something the autotools suite can help with) and an
> installer (or package if you're installing onto a system that has a
> package manager). From a Windows perspective, it's the same as the
> difference between Visual Studio and something like InstallShield or
> NSIS.
>
> One trick that may help is automake's "DESTDIR" variable, which allows
> you to create a "degenerate" package (i.e., something that doesn't
> allow you to do fancy system setup -- not unlike installing a Windows
> app from a .zip file). When you're doing make install, try instead:
>
> make install DESTDIR=/tmp/staging
>
> Automake will build everything as if it's going to install to your --
> prefix (including embedding references to your prefix in the
> appropriate places) and then at the last minute, it will take the
> files it was going to install and "destdir" them at /tmp/staging.
> Then you can simply tar/gz the files at /tmp/ staging and ship those
> to your customers. Or zip them.
>
> Cheers,
> Andre
Hi,
One more comment to add about staged build/installs: the 'distcheck'
target uses DESTDIR=something-temporary when checking to make sure the
build is properly packaged. To quote an excerpt of distcheck:
- - - - - - >8 snip 8< - - - - - - -
dc_install_base=`$(am__cd) $(distdir)/_inst && pwd | sed -e
's,^[^:\\/]:[\\/],/,'` \
&& dc_destdir="$${TMPDIR-/tmp}/am-dc-/" \
&& cd $(distdir)/_build \
&& ../configure --srcdir=.. --prefix="$$dc_install_base" \
$(DISTCHECK_CONFIGURE_FLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) dvi \
&& $(MAKE) $(AM_MAKEFLAGS) check \
&& $(MAKE) $(AM_MAKEFLAGS) install \
&& $(MAKE) $(AM_MAKEFLAGS) installcheck \
&& $(MAKE) $(AM_MAKEFLAGS) uninstall \
&& $(MAKE) $(AM_MAKEFLAGS) distuninstallcheck_dir="$$dc_install_base"
\
distuninstallcheck \
&& chmod -R a-w "$$dc_install_base" \
&& ({ \
(cd ../.. && umask 077 && mkdir "$$dc_destdir") \
&& $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" install \
&& $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" uninstall \
&& $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" \
distuninstallcheck_dir="$$dc_destdir" distuninstallcheck; \
} || { rm -rf "$$dc_destdir"; exit 1; }) \
&& rm -rf "$$dc_destdir" \
&& $(MAKE) $(AM_MAKEFLAGS) dist \
&& rm -rf $(DIST_ARCHIVES) \
&& $(MAKE) $(AM_MAKEFLAGS) distcleancheck
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
- - - - - - >8 snip 8< - - - - - - -
I recommend at least 'make distcheck' for validating packaging.
Fang
Re: distdir unset in subdir Makefiles?
> > DF> In one instance, I wished to manually inspect the result of one > > of > > DF> the subdirectories' "make distdir", but had to pass in these two > > variables > > DF> by hand, slightly inconvenient. Is there a rationale for omitting > > these > > DF> two variables in subdir's Makefile.in's? > > The suggestion is that one might occassionally need to do `make distdir' > in a subdirectory of a project. (No subpackages are involved.) > > My answer was that the advantage of shortening each makefile by two > lines is bigger than the discomfort reported, because the need for > non-top `make distdir' is very rare. > (But I was not sure whether this is the right answer, so I decided to > wait for a better answer from someone else.) Hi, Well, in any case, it's not too difficult for me to add my own target, say 'distdir-subdir' and pass the $(PACKAGE)-$(VERSION)[/$(subdir)] paths in that way, calling make recursively. I have a global Makefile.include that is include-inlined into every Makefile.in by automake for various useful variable definitions and phony targets. David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
distdir unset in subdir Makefiles?
Hi, I've noticed that the distdir variable in generated Makefile.in's only appears in the top-level Makefile.in, however, it is not set in subdirectories' Makefile.in's. Is this intentional? According to the top Makefile.in, distdir and top_distdir are passed down recursively during a "make distdir", set to $(PACKAGE)-$(VERSION) and subdirs. In one instance, I wished to manually inspect the result of one of the subdirectories' "make distdir", but had to pass in these two variables by hand, slightly inconvenient. Is there a rationale for omitting these two variables in subdir's Makefile.in's? Thanks in advance. Fang
Re: robustifying remove_distdir?
In reply to myself:
> Is there a way of making the "rm -rf" more robust? Maybe with some sort
> of "while distdir exists, try removing" loop?
So far this works for me:
In automake-1.9/am/distdir.am:
--->8 patch snip 8<-
am__remove_distdir = \
{ test ! -d $(distdir) \
|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
- && rm -fr $(distdir); }; }
+ && { until rm -fr $(distdir); do :; done; }; }; }
endif %?TOPDIR_P%
.PHONY: distdir
--->8 patch snip 8<-
Comments?
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
robustifying remove_distdir?
Hi,
I'm have a strange problem with automake-1.9.5, where
"make dist" is dying at the very end on $(am__remove_distdir) because
the "rm -rf" fails.
{ test ! -d myproj || { find myproj -type d ! -perm -200 -exec chmod u+w {} ';'
&&
rm -fr myproj; }; }
rm: cannot remove directory `myproj/test/parser/connect': Directory not empty
rm: cannot remove directory `myproj/test/parser/flow': Directory not empty
rm: cannot remove directory `myproj/test/parser/param': Directory not empty
rm: cannot remove directory `myproj/test/parser/process': Directory not empty
Where:
am__remove_distdir = \
{ test ! -d $(distdir) \
|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
&& rm -fr $(distdir); }; }
Looking inside the remnants of the distdir, I find that files named
towards the end of the alphabetical ordering failed to be removed, likely
an artifact of the shell or file system? (Yes, there are *hundreds* of
files in those dist-directories.) This has happened to me occasionally on
FreeBSD, linux, and Darwin (nondeterminstically). By hand, one ends up
"rm -rf"-ing several times until removal succeeds.
Is there a way of making the "rm -rf" more robust? Maybe with some sort
of "while distdir exists, try removing" loop?
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
Re: Complex commands in TESTS
> is there a way to have automake execute complex commands as tests? For > example, currently I use something like: > > TESTS = numberAtoms input.sh > > But it would be nice to have, for instance, a command with arguments like > input.sh a b c > executed; is that possible, when yes, how? I've tried quoting so far > (TESTS = numberAtoms "input.sh a b c") but it doesn't work. Hi, One simple way is to put the invocation commands into a built shell script for each test: TESTS = my_test.sh my_test.sh: echo "#!/bin/sh" > $@ echo "command arg1 arg2 arg3" >> $@ chmod +x $@ HTH David
Re: Automake problem: one makefile for everything
> and I want a Makefile.am in the top-level source directory that > compiles main1.c and main2.c into one library (say libmain.la) and > mod1.c and mod2.c into libmod.la in the modules directory. Simple > request huh? But in *one* Makefile.am. How do I do it? > > This doesn't do the job: > lib_LTLIBRARIES = libmain.la modules/libmod.la > libmain_la_SOURCES = main1.c main2.c > libmod_la_SOURCES = modules/mod1.c modules/mod2.c Hi, Did you mean: modules_libmod_la_SOURCES = ... ? You said "... libmod.la in the modules directory." > libtool doesn't like directory names in the lib_LTLIBRARIES variable. > But if I go ... > > > lib_LTLIBRARIES = libmain.la libmod.la and modules/libmod.la? > ...then everything gets built in the top-level directory and I don't > want that. > > > Can anyone help? My only work-around at present is to have a separate > Makefile in the modules sub-directory, but that won't work anymore > because I'm building a binary in the top-level Makefile that depends on > both earlier libraries, while libmod also depends on libmain, i.e. > > > binary -> depends on modules/libmod.la and libmain.la > modules/libmod.la -> depends on libmain.la > > > If I use separate Makefiles, I'm going to need three to get around the > dependencies and to get the build order right, and that's going to get > ugly. David Fang
Re: How to remove "-O2" on Makefile generated by autoconf/make
> When I use autoconf/automake tools to generate makefile for my package, the > CXXFLAGS is always added "-O2" by tools, while I don't want to use for > debuging. > Is it possible to remove it from options of configure command or some other > ways better than removing it manually everytime on Makefile? Hi, I think a combination of AM_CXXFLAGS = and configure CXXFLAGS="" will work. Probably just the latter is enough. I believe -g and -O2 are picked up by default by autoconf when nothing is specified. David Fang
Re: Hide issued compiler commands
> I have started recently to switch some of the OSS projects I work on to > automake. In one of this projects we used autoconf with our own hand > made Makefile.in. This Makefile.in hided the issued compiler commands > and instead printed something like "Compiling src/common/list.c.." or > "Linking src/prog/prog1..." (kinda like samba is doing I think). > > How should I do this with automake based project ? Hi, From GNUMake (indepedent of automake), you can declare .SILENT: to prevent commands from being echoed. You can also prefix individual shell commands with @ to suppress echoing in the individual target scripts. If you're using libtool with automake, add to configure.ac: LIBTOOL="$LIBTOOL --silent" to keep libtool quiet unconditionally. That should cover most things. What remain are explicit echo commands. HTH. David Fang
Re: broken make distclean...
> I recently started seeing the following problem doing a make distclean: > > rm -rf ../libsrc/.deps ./.deps Hi, (Autotools amateur here, so please correct me nicely if I'm wrong! :) ) I'd say the above line is the problem is the above line, where your Makefile is touching something that's not an immediate subdirectory, i.e. cross-removing .deps files in ../libsrc while it's operating in libsrc4. Generally one should avoid that because the .deps files are always generated and read by the Makefiles. distclean is particularly sensitive to this. Does your Makefile .am have ../libsrc in the SUBDIRS? I'm guessing that might have caused it. When distclean cleaned the directories in reverse order, it pulled the wheels out from under the cart. (complete stab in the dark) If libsrc really depends on something being built in a sister directory, you might resort to other tricks to make a correct build, like depending on SUBDIR ordering, making cross- directory links, or explicit jumps to that directory ($(MAKE) -C foo). > rm -f Makefile > make[1]: Leaving directory `/home/ed/netcdf-3/libsrc4' > Making distclean in libsrc > make[1]: Entering directory `/home/ed/netcdf-3/libsrc' > Makefile:364: .deps/attr.Plo: No such file or directory > Makefile:365: .deps/dim.Plo: No such file or directory > Makefile:366: .deps/error.Plo: No such file or directory > Makefile:367: .deps/libvers.Plo: No such file or directory > Makefile:368: .deps/nc.Plo: No such file or directory > Makefile:369: .deps/ncx.Plo: No such file or directory > Makefile:370: .deps/posixio.Plo: No such file or directory > Makefile:371: .deps/putget.Plo: No such file or directory > Makefile:372: .deps/string.Plo: No such file or directory > Makefile:373: .deps/v1hpg.Plo: No such file or directory > Makefile:374: .deps/v2i.Plo: No such file or directory > Makefile:375: .deps/var.Plo: No such file or directory > make[1]: *** No rule to make target `.deps/var.Plo'. Stop. > make[1]: Leaving directory `/home/ed/netcdf-3/libsrc' > make: *** [ > distclean-recursive] Error 1 > > I've got no clue what's going on here. Hope this helps. David Fang
Re: Need a way to pass options to libtool
Hi, I ran across a thread about adding options to libtool in automake or autoconf (since I was looking for the same answer myself). (Last post May 29, 2004) I've devised a little autoconf solution that may help: In configure.in, somwhere after AC_PROG_LIBTOOL, add (e.g.): LIBTOOL="$LIBTOOL --silent" or whatever flags you wish, and this results in: LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent in all Makefiles generated by that autoconf'd configure script. With a little clever variable manipulation, you may be able to substitute "--silent" with more user-options. Perhaps per-Makefile libtool flags? Regards, David "just-learned-automake-autoconf-libtool-this-past-week -and-thought-it-would-be-a-good-time-to-subscribe" Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- *gag* work in progress
