
Entd Development/Test Cycle
===========================

Most entd features and fixes can be developed and unit tested entirely in the
source directory of entd while in your chroot.  Entd can be built for your
target platform using only the scons file (no need for emerge or ebuild), and
can be launched using scripts/run_32bit.sh, or the run_tests.sh script from
Entd.

If you are not using /build/x86-generic as your x86-generic board, set
DEFAULT_BOARD to the board you are using.

To build an x86 version of entd, run...

  $ cd platform/entd
  $ scons CHOST=i686-pc-linux-gnu SYSROOT=/build/$DEFAULT_BOARD/

This will create a platform/entd/out/i686-pc-linux-gnu/ directory and place
the target executable there.

Then, to launch entd...

  $ ./run_32bit.sh ./out/i686-pc-linux-gnu/entd
  [0721/093224:INFO:main.cc(130)] Starting entd
  [0721/103352:WARNING:entd.cc(375)] Problem loading chromeos shared object: Couldn't load libcros from: /opt/google/chrome/chromeos/libcros.so error: /opt/google/chrome/chromeos/libcros.so: cannot open shared object file: No such file or directory
  [0721/093224:ERROR:entd.cc(471)] Can't determine hostname from username: 
  [0721/093224:INFO:main.cc(208)] Exiting entd with code: 1

Entd takes a number of command line arguments.  The error message we just
got is a sign that we forgot --username.  In order to pass arguments through
the run_32bit.sh script, we need to separate the script's arguments from
entd's, using --, as in...

  $ ./run_32bit.sh ./out/i686-pc-linux-gnu/entd -- \
    --username=user@example.com
  [0721/094034:INFO:main.cc(130)] Starting entd
  ...
  [0721/094034:ERROR:entd.cc(531)] No policy file.
  [0721/094034:INFO:main.cc(208)] Exiting entd with code: 1

Here we've failed to start because we haven't specified a policy file, we can
do that using --policy.  Before that, we'll introduce a shell variable to make
the command lines slightly shorter...

  $ ENTD="./run_32bit.sh ./out/i686-pc-linux-gnu/entd --"
  $ $ENTD --username=user@example.com --policy=test_data/hello-world.js

This time you'll notice that entd doesn't exit on its own.  This is an
unfortunate side effect of the way it catches signals.  It's not an issue
in production, where we expect entd to keep running, but can be troublesome
for testing.  You can add the --allow-dirty-exit, which prevents entd from
registering to handle signal events, and therefore allows it to exit when
the policy execution completes.  Press Ctrl-C to terminate entd, and then
run...

  $ $ENTD --username=user@example.com --policy=test_data/hello-world.js \
    --allow-dirty-exit
  [0721/094725:INFO:main.cc(130)] Starting entd
  hello world
  [0721/094725:INFO:entd.cc(540)] Policy loaded.
  [0721/094725:INFO:main.cc(208)] Exiting entd with code: 0

And now you've had your first successful run of the Enterprise Daemon.  Go you.

For now, entd command line arguments are only documented in source.  You'll
have to read through the top of main.cc for usage information, or read through
the run_tests.sh script for examples.

The run_tests.sh script runs the entd unit tests, as you might have guessed.
It's a little janky, but it gets the job done.  It's simple to start, and looks
something like this...

  $ ./run_tests.sh
  PASS: hello-world.js
  PASS: bad-onload.js
  ...
  PASS: simple-shutdown.js
  PASS: simple-callback.js

  Tests completed: 28
  TESTS FAILED: 0

Many of the unit tests require you to have PKCS11 set up in your development
environment.  See the README.pkcs11 file in this directory for details on how
to get that running.

You should make sure to write new unit tests for any new functionality,
regression tests for bug fixes, and ensure that all tests pass before submitting
a CL for review.