RepoMirrors
/
ceph
mirror of https://github.com/ceph/ceph
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ceph/Makefile.am

38 lines
1.1 KiB
Makefile
Raw Normal View History

first pass at autoconf and automake
2008-01-28 02:12:20 +00:00
AUTOMAKE_OPTIONS = gnu
rpm: Include ceph.spec in release tarball. This lets users say "rpmbuild -ta ceph-XXX.tgz". Closes: #1521 Signed-off-by: Tommi Virtanen <tommi.virtanen@dreamhost.com>
2011-09-08 19:59:05 +00:00
EXTRA_DIST = autogen.sh ceph.spec.in ceph.spec
Use Google Test framework for unit tests. Use ``make check`` to run the tests. The src/gtest directory comes from ``svn export http://googletest.googlecode.com/svn/tags/release-1.5.0 src/gtest`` and running "git add -f src/gtest". gtest is licensed under the New BSD license, see src/gtest/COPYING. For more on Google Test, see http://code.google.com/p/googletest/ Changed autogen.sh regenerate gtest automake files too. Make sure to run ``./autogen.sh && ./configure`` after merging this commit, or incremental builds may fail. The automake integration is inspired heavily by the protobuf project, and may still be problematic. Make git ignore files generated by gtest compilation. Currently putting in just one new-style unit test, refactoring old tests to fit will come in separate commits. Note: if you are starting daemons, listening on TCP ports, using multiple machines, mounting filesystems, etc, it's not a unit test and does not belong in this setup. A framework for system/integration tests will be provided later.
2011-01-07 21:15:40 +00:00
# the "." here makes sure check-local builds gtest before it is used
qa: do not use automake for workunit makefiles Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
2011-06-14 19:53:33 +00:00
SUBDIRS = . src man
Use Google Test framework for unit tests. Use ``make check`` to run the tests. The src/gtest directory comes from ``svn export http://googletest.googlecode.com/svn/tags/release-1.5.0 src/gtest`` and running "git add -f src/gtest". gtest is licensed under the New BSD license, see src/gtest/COPYING. For more on Google Test, see http://code.google.com/p/googletest/ Changed autogen.sh regenerate gtest automake files too. Make sure to run ``./autogen.sh && ./configure`` after merging this commit, or incremental builds may fail. The automake integration is inspired heavily by the protobuf project, and may still be problematic. Make git ignore files generated by gtest compilation. Currently putting in just one new-style unit test, refactoring old tests to fit will come in separate commits. Note: if you are starting daemons, listening on TCP ports, using multiple machines, mounting filesystems, etc, it's not a unit test and does not belong in this setup. A framework for system/integration tests will be provided later.
2011-01-07 21:15:40 +00:00
Also distribute pre-downloaded tarballs. Found by "make distcheck".
2011-01-13 21:38:40 +00:00
EXTRA_DIST += \
src/test/run-cli-tests \
Makefile: include run-cli-tests-maybe-unset-ccache in dist tarball. Apparently "make distcheck" has been broken for 3 months; I find that hard to believe, but that's what it looks like. Signed-off-by: Tommi Virtanen <tommi.virtanen@dreamhost.com>
2011-09-23 22:15:13 +00:00
src/test/run-cli-tests-maybe-unset-ccache \
Include the cli tests in a dist tarball. Found by "make distcheck".
2011-01-14 18:33:31 +00:00
src/test/cli \
debian: add udev rules Add /lib/udev/rules.d/50-rbd.rules to debian package. Signed-off-by: Samuel Just <samuel.just@dreamhost.com>
2011-03-08 00:03:08 +00:00
src/test/downloads \
udev/50-rbd.rules
qa: do not use automake for workunit makefiles Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
2011-06-14 19:53:33 +00:00
Makefile.am: build gtest in debug builds Formerly, we only built gtest when doing 'make check'. However, the librados-api tests, which are built in debug mode for the 'all' target, also use gtest. So build it when needed. Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
2011-08-09 22:21:53 +00:00
all-local:
if WITH_DEBUG
# We need gtest to build the rados-api tests. We only build those in
# a debug build, though.
Makefile: link gtest statically The problem: - the unittests link against gtest, and gtest is not installed. that's normally fine, but... - rbd and rados api unit tests link against gtest, and are installed by 'make install'. they are needed for teuthology runs, etc. - if we build gtest as an .la library, we can only control whether *all* or *no* .la libraries are linked statically. - we want librados to be linked dynamically. The solution: - build gtest as .a instead of a libtool library - link it statically, always. Unit test binaries are bigger now. Oh well... Fixes: #2331 Signed-off-by: Sage Weil <sage@inktank.com>
2012-06-13 18:05:43 +00:00
@cd src/gtest && $(MAKE) $(AM_MAKEFLAGS) lib/libgtest.a lib/libgtest_main.a
Makefile.am: build gtest in debug builds Formerly, we only built gtest when doing 'make check'. However, the librados-api tests, which are built in debug mode for the 'all' target, also use gtest. So build it when needed. Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
2011-08-09 22:21:53 +00:00
endif
Use Google Test framework for unit tests. Use ``make check`` to run the tests. The src/gtest directory comes from ``svn export http://googletest.googlecode.com/svn/tags/release-1.5.0 src/gtest`` and running "git add -f src/gtest". gtest is licensed under the New BSD license, see src/gtest/COPYING. For more on Google Test, see http://code.google.com/p/googletest/ Changed autogen.sh regenerate gtest automake files too. Make sure to run ``./autogen.sh && ./configure`` after merging this commit, or incremental builds may fail. The automake integration is inspired heavily by the protobuf project, and may still be problematic. Make git ignore files generated by gtest compilation. Currently putting in just one new-style unit test, refactoring old tests to fit will come in separate commits. Note: if you are starting daemons, listening on TCP ports, using multiple machines, mounting filesystems, etc, it's not a unit test and does not belong in this setup. A framework for system/integration tests will be provided later.
2011-01-07 21:15:40 +00:00
Makefile.am: build gtest in debug builds Formerly, we only built gtest when doing 'make check'. However, the librados-api tests, which are built in debug mode for the 'all' target, also use gtest. So build it when needed. Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
2011-08-09 22:21:53 +00:00
check-local:
# We build gtest this way, instead of using SUBDIRS, because with that,
# gtest's own tests would be run and that would slow us down.
Makefile: link gtest statically The problem: - the unittests link against gtest, and gtest is not installed. that's normally fine, but... - rbd and rados api unit tests link against gtest, and are installed by 'make install'. they are needed for teuthology runs, etc. - if we build gtest as an .la library, we can only control whether *all* or *no* .la libraries are linked statically. - we want librados to be linked dynamically. The solution: - build gtest as .a instead of a libtool library - link it statically, always. Unit test binaries are bigger now. Oh well... Fixes: #2331 Signed-off-by: Sage Weil <sage@inktank.com>
2012-06-13 18:05:43 +00:00
@cd src/gtest && $(MAKE) $(AM_MAKEFLAGS) lib/libgtest.a lib/libgtest_main.a
Add CLI tests for osdmaptool and friends. Uses a python package "cram" as test runner. Requires PIP (python-pip.deb) installed on the build machine, to actually run these tests. The cram application itself is included as a tarball that gets installed in a virtualenv when the tests are run. cram is GPL.
2011-01-12 00:43:46 +00:00
# exercise cli tools
Teach run-cli-tests about build dirs. An optional argument points can tell it where to put generated files (in this case, virtualenv). Provide the argument in Makefile.am. Options are still passed to cram, so you can say "./src/test/run-cli-tests -i".
2011-01-13 20:59:11 +00:00
$(srcdir)/src/test/run-cli-tests '$(top_builddir)/src/test'
Add CLI tests for osdmaptool and friends. Uses a python package "cram" as test runner. Requires PIP (python-pip.deb) installed on the build machine, to actually run these tests. The cram application itself is included as a tarball that gets installed in a virtualenv when the tests are run. cram is GPL.
2011-01-12 00:43:46 +00:00
Use Google Test framework for unit tests. Use ``make check`` to run the tests. The src/gtest directory comes from ``svn export http://googletest.googlecode.com/svn/tags/release-1.5.0 src/gtest`` and running "git add -f src/gtest". gtest is licensed under the New BSD license, see src/gtest/COPYING. For more on Google Test, see http://code.google.com/p/googletest/ Changed autogen.sh regenerate gtest automake files too. Make sure to run ``./autogen.sh && ./configure`` after merging this commit, or incremental builds may fail. The automake integration is inspired heavily by the protobuf project, and may still be problematic. Make git ignore files generated by gtest compilation. Currently putting in just one new-style unit test, refactoring old tests to fit will come in separate commits. Note: if you are starting daemons, listening on TCP ports, using multiple machines, mounting filesystems, etc, it's not a unit test and does not belong in this setup. A framework for system/integration tests will be provided later.
2011-01-07 21:15:40 +00:00
# "make distclean" both runs this and recurses into src/gtest, if
# gtest is in DIST_SUBDIRS. Take extra care to not fail when
# effectively cleaned twice.
clean-local:
@if test -e src/gtest/Makefile; then \
echo "Making clean in src/gtest"; \
cd src/gtest && $(MAKE) $(AM_MAKEFLAGS) clean; \
fi
Clean up test virtualenv on "make clean". Found by "make distcheck".
2011-01-14 18:35:20 +00:00
@rm -rf src/test/virtualenv