Building Trusted and Untrusted Modules with Scons

[George Robinson]

Greetings,

I’ve been playing around with Native Client for some weeks and I’m stumped as to how to compile both trusted (a.out) and untrusted (.nexe) modules without running them as part of the test suite in SConstruct.

I’ve been trying to deconstruct the SConstruct file but it’s over 4000 lines of Python. Therefore, I was wondering if there is any documentation on how to build and link both trusted and untrusted modules with the .scons files in the Native Client source?

If not, should I just add a .scons file to the nonvariant_tests in SConstruct and leave it be? For example:

nonvariant_tests = [

    #### ALPHABETICALLY SORTED ####

    'tests/barebones/nacl.scons',

    'tests/chrome_extension/nacl.scons',

    'tests/custom_desc/nacl.scons',

    'tests/faulted_thread_queue/nacl.scons',

    'tests/gold_plugin/nacl.scons',

    'tests/imc_sockets/nacl.scons',

    'tests/minnacl/nacl.scons',

    ‘exanple/my-example.scons’,

    etc

The end goal is to compile a simple program that can create sandboxes like the multiple_sandboxes example:

#include <stdio.h>

#include "native_client/src/trusted/service_runtime/load_file.h"

#include "native_client/src/trusted/service_runtime/nacl_all_modules.h"

#include "native_client/src/trusted/service_runtime/nacl_app.h"

#include "native_client/src/trusted/service_runtime/sel_ldr.h"

int

main(int argc, char **argv)

{

    struct NaClApp app;

    // create sandboxes here

    NaClExit(0);

}

I don’t want to compile using the Native Client SDK because I would like to run both the trusted and untrusted modules with and without modifications to the Native Client source code - hence I have the buildable source checked out and not the SDK.

Many thanks!

[Mark Seaborn]

On 24 June 2015 at 07:55, George Robinson <george.ro...@ucl.ac.uk> wrote:

Greetings,

I’ve been playing around with Native Client for some weeks and I’m stumped as to how to compile both trusted (a.out) and untrusted (.nexe) modules without running them as part of the test suite in SConstruct.

The following will run one particular test (as an example):

  ./scons run_multidomain_test

But if you only want to build the executables that the test uses, you can do:

  ./scons multidomain_test_guest multidomain_test_host

I'm not sure if that answers your question?

 

The end goal is to compile a simple program that can create sandboxes like the multiple_sandboxes example, but outside the tests dir and without all the extra setup needed for the tests:

There is nothing special about the "tests" directory.  You can place a .scons file in a different directory and it will work the same.

I'm not sure what you mean by "without all the extra setup needed for the tests".  Do you mean setup in the .scons file or in the .c file?  You can omit CommandTest() and AddNodeToTestSuite() from a .scons file, and you'll still be able to build the executables specified in the .scons file.

Cheers,

Mark

[George Robinson]

Thanks Mark!

The question was more the following:

We've observed that the SConstruct file is quite significant - and that most of our CPU time in recompiling our code is spent in Python - which I presume is a result of the SCons scripts. Therefore, I was wondering if there is an option to strip this down to the bare minimum? It's not a deal-breaker at all, but would just save some time between writing code, recompiling and re-executing, etc.

Thanks!