OLD | NEW |
---|---|
(Empty) | |
1 | |
2 Entd Development/Test Cycle | |
3 =========================== | |
4 | |
5 Most entd features and fixes can be devloped and unit tested entirely in the | |
gauravsh
2010/07/21 17:50:37
s/devloped/developed/
| |
6 source directory of entd while in your chroot. Entd can be built for your | |
7 target platform using only the scons file (no need for emerge or ebuild), and | |
8 can be launched using scripts/run_32bit.sh, or the run_tests.sh script from | |
9 Entd. | |
10 | |
11 To build an x86 versioin of entd, run... | |
12 | |
13 $ cd platform/entd | |
14 $ scons CHOST=i686-pc-linux-gnu SYSROOT=/build/x86-generic/ | |
15 | |
16 This will create a platform/entd/out/i686-pc-linux-gnu/ directory and place | |
17 the target executable there. | |
18 | |
19 Then, to launch entd... | |
20 | |
21 $ ../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd | |
22 [0721/093224:INFO:main.cc(130)] Starting entd | |
23 ... | |
24 [0721/093224:ERROR:entd.cc(471)] Can't determine hostname from username: | |
25 [0721/093224:INFO:main.cc(208)] Exiting entd with code: 1 | |
26 | |
27 Entd takes a number of command line arguments. The error message we just | |
28 got is a sign that we forgot --username. In order to pass arguments through | |
29 the run_32bit.sh script, we need to separate the script's arguments from | |
30 entd's, using --, as in... | |
31 | |
32 $ ../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd -- \ | |
33 --username=user@example.com | |
34 [0721/094034:INFO:main.cc(130)] Starting entd | |
35 ... | |
36 [0721/094034:ERROR:entd.cc(531)] No policy file. | |
37 [0721/094034:INFO:main.cc(208)] Exiting entd with code: 1 | |
38 | |
39 Here we've failed to start because we haven't specified a policy file, we can | |
40 do that using --policy. Before that, we'll introduce a shell variable to make | |
41 the command lines slightly shorter... | |
42 | |
43 $ ENTD="../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd --" | |
44 $ $ENTD --username=user@example.com --policy=test_data/hello-world.js | |
45 | |
46 This time you'll notice that entd doesn't exit on its own. This is an | |
47 unfortunate side effect of the way it catches signals. It's not an issue | |
48 in production, where we expect entd to keep running, but can be troublesome | |
49 for testing. You can add the --allow-dirty-exit, which prevents entd from | |
50 registering to handle signal events, and therefore allows it to exit when | |
51 the policy execution completes. Press Ctrl-C to terminate entd, and then | |
52 run... | |
53 | |
54 $ $ENTD --username=user@example.com --policy=test_data/hello-world.js \ | |
55 --allow-dirty-exit | |
56 [0721/094725:INFO:main.cc(130)] Starting entd | |
57 hello world | |
58 [0721/094725:INFO:entd.cc(540)] Policy loaded. | |
59 [0721/094725:INFO:main.cc(208)] Exiting entd with code: 0 | |
60 | |
61 And now you've had your first successful run of the Enterprise Daemon. Go you. | |
62 | |
63 For now, entd command line arguments are only documented in source. You'll | |
64 have to read through the top of main.cc for usage information, or read through | |
65 the run_tests.sh script for examples. | |
66 | |
67 The run_tests.sh script runs the entd unit tests, as you might have guessed. | |
68 It's a little janky, but it gets the job done. It's simple to start, and looks | |
69 something like this... | |
70 | |
71 $ ./run_tests.sh | |
72 PASS: hello-world.js | |
73 PASS: bad-onload.js | |
74 ... | |
75 PASS: simple-shutdown.js | |
76 PASS: simple-callback.js | |
77 | |
78 Tests completed: 28 | |
79 TESTS FAILED: 0 | |
80 | |
81 Many of the unit tests require you to have PKCS11 set up in your development | |
82 environment. See the README.pkcs11 file in this directory for details on how | |
83 to get that running. | |
84 | |
85 You should make sure to write new unit tests for any new functionality, | |
86 regression tests for bug fixes, and ensure that all tests pass before submitting | |
87 a CL for review. | |
88 | |
89 | |
OLD | NEW |