Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I do this for builds for multiple platforms (rather than debug/release) but the concept's the same. The basic idea is that you need 2 files in the project root - a SConstruct to set up the build directories (or "variant directories" as they are known in scons), then a SConscript that describes the actual build steps.</p> <p>In the SConstruct file you'd specify the variant directory and its corresponding source directory:</p> <pre><code>SConscript(dirs='.', variant_dir=variant_dir, duplicate=False, exports="env") </code></pre> <p>Now you want variant_dir to depend on a flag. You'd use AddOption or Variables to do this. Here's one example of a complete top-level SConstruct to do that:</p> <pre><code># build with `scons --debug-build` for debug. AddOption( '--debug-build', action='store_true', help='debug build', default=False) env = Environment() if GetOption('debug_build'): env.ParseFlags('-DDEBUG') variant_dir = 'build/debug' else: variant_dir = 'build/release' SConscript(dirs='.', variant_dir=variant_dir, duplicate=False, exports="env") </code></pre> <p>AddOption is easiest to use, but if you use Variables then you can cache the result between runs, rather than having to spell out "scons --debug-build" each time.</p> <p>All the directory setup and associated cruft is in the SConstruct. Now the SConscript file is quite simple and doesn't need to worry about build directories at all.</p> <pre><code>Import('env') env.Program(target='foo_prog', source=['foo/main.cpp', 'lib/libmoo.a']) # foo_prog since foo already exists as the name of the directory... </code></pre> <p>This is about the simplest way I've found to set up different build directories without getting weird errors. It's also pretty flexible - you can add different platform builds just by modifying the "env" in the top-level script without having to alter the actual meat of the build.</p> <p>The only spanner in the works in your question is the way to compile autoconf-style projects directly from SCons. The easiest way is probably with a couple of Command() calls, but SCons likes to know about the inputs and outputs of each step, so this can get hacky. Also, you have to rely on the autoconf build having a correct VPATH setup - some projects don't work if you try and compile outside the source tree. Anyway, a way to compile autoconf projects would be something like this:</p> <pre><code>import os Import('env') # get the path to the configure script from the "moo" source directory conf = env.File('moo/configure').srcnode().abspath # Create the "moo" build directory in the build dir build_dir = env.Dir('.').path moo_dir = os.path.join(build_dir, 'moo') Mkdir(moo_dir) # run configure from within the moo dir env.Command('moo/Makefile', 'moo/Makefile.am', conf, chdir=moo_dir) # run make in the moo dir env.Command('moo/libmoo.a', 'moo/Makefile', 'make', chdir=moo_dir) env.Program(target='foo_prog', source=['foo/main.cpp', 'moo/libmoo.a']) </code></pre> <p>Running the configure step from the source directory while the current working directory is somewhere in the build hierarchy is awkward. The make step is less messy, but still needs to know about the current build directory. Since you specify "libmoo.a" as an output of the make step and libmoo.a as an input to the program, all the dependencies Just Work, so a parallel build works fine. Parallel builds only break down when you fudge dependencies too much.</p>
    singulars
    1. This table or related slice is empty.
    1. POSCons: Separate debug/release build dirs with a hierarchical build
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USrichq
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSCons: Separate debug/release build dirs with a hierarchical build
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload