2
0
mirror of https://github.com/boostorg/build.git synced 2026-02-14 12:42:11 +00:00
Files
build/test/searched_lib.py
Vladimir Prus 5b79cb74ed Patch from Andre Hentz.
* new/builtin.jam
  - register builtin.response-generator with 'register-linker', to
    take advantange of 'link-action'. Convert <library-path>,
    <find-static-library> and <find-shared-library> into on-target
    variables using toolset.flags.
  (builtin.response-file) Output variables for library path to response
    file.
  (searched-lib-generator.run): Assign 'null-action' instance to the
  generated target, to carry properties. Correct prototype and workaround
  some, as-yet-unknown problem.

* test/searched_lib.py: New test (added by me).


[SVN r18121]
2003-03-28 09:20:58 +00:00

69 lines
1.8 KiB
Python

#!/usr/bin/python
# Test usage of searched-libs: one which are found via -l
# switch to the linker/compiler.
from BoostBuild import Tester
import string
t = Tester()
# To start with, we have to prepate a library to link with
t.write("lib/project-root.jam", "import gcc ; ")
t.write("lib/Jamfile", "lib test_lib : test_lib.cpp ;")
t.write("lib/test_lib.cpp", "void foo() {}\n");
t.run_build_system(subdir="lib")
t.expect_addition("lib/bin/$toolset/debug/test_lib.dll")
t.copy("lib/bin/$toolset/debug/test_lib.dll", "lib/libtest_lib.dll")
# A regression test: <library>property referring to
# searched-lib was mishandled. As the result, we were
# putting target name to the command line!
# Note that
# g++ ...... <.>z
# works nicely in some cases, sending output from compiler
# to file 'z'.
# This problem shows up when searched libs are in usage
# requirements.
t.write('project-root.jam', 'import gcc ;')
t.write('Jamfile', 'exe main : main.cpp d/d2/a ;')
t.write("main.cpp", """
int main() { return 0; }
""")
t.write('d/d2/Jamfile', """
lib test_lib : : <name>test_lib <search>../../lib ;
lib a : a.cpp : : : <library>test_lib ;
""")
t.write('d/d2/a.cpp', """
""")
t.run_build_system()
# A regression test. Searched targets were not associated
# with any properties. For that reason, if the same searched
# lib is generated with two different properties, we had an
# error saying they are actualized to the same Jam target name.
t.write("project-root.jam", "")
t.write("a.cpp", "")
# The 'l' library will be built in two variants:
# 'debug' (directly requested) and 'release' (requested
# from 'a').
t.write("Jamfile", """
exe a : a.cpp l/<variant>release ;
lib l : : <name>l_d <variant>debug ;
lib l : : <name>l_r <variant>release ;
""")
t.run_build_system("-n")
t.cleanup()