Get open-vcdiff building on Linux and Mac (in SCons) using...

Get open-vcdiff building on Linux and Mac (in SCons) using
captured values for generating a config.h file.

Builds base/sdch_{filter,manager}.cc on all platforms and links
the 'sdch' library.

Add sdch to the SCons configuration loaded on Mac and Linux.

Removes platform #ifs in net/base/filter.cc initialization code
(reverting r2740).

B=2662

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=2710

[Mark Mentovai, 2008-09-30 00:56:26]

LG™

http://codereview.chromium.org/5204/diff/1/2
File sdch/SConscript (right):

http://codereview.chromium.org/5204/diff/1/2#newcode88
Line 88: def AutoConfig(target, source, env):
Cool, I like this.  It would be useful to eventually make this available more
globally, so we can use it for other builds like libxml and libevent.

http://codereview.chromium.org/5204/diff/1/2#newcode109
Line 109: contents = contents.replace(undef, definition)
How can we be sure that these replacements will be anchored at the beginning of
a line?  I can envision this transforming comments inappropriately.  Can we do a
regex substitution for this too?

http://codereview.chromium.org/5204/diff/1/2#newcode117
Line 117: env.Command('$OPEN_VCDIFF_DIR/src/config.h',
Refresh my memory about how these work.  If it's target and then dependencies,
can we do something to ensure that config.h will be rebuilt not only if
config.h.in changes but also if the list of defines changes?  Make config.h
depend on the SConscript, maybe?

http://codereview.chromium.org/5204/diff/1/2#newcode120
Line 120: DEFINES=defines)
This generates config.h next to config.h.in, right?  Can we put it somewhere in
the build directory instead (and set the include path appropriately?)  I don't
like littering the source directory, it makes it much harder to clean a build
and it makes it so much more likely that someone will come along and
inadvertently add the generated file to the svn repository.

[sgk, 2008-09-30 01:26:50]

http://codereview.chromium.org/5204/diff/1/2
File sdch/SConscript (right):

http://codereview.chromium.org/5204/diff/1/2#newcode88
Line 88: def AutoConfig(target, source, env):
On 2008/09/30 00:56:26, Mark Mentovai wrote:
> Cool, I like this.  It would be useful to eventually make this available more
> globally, so we can use it for other builds like libxml and libevent.

Agreed.  Stuff like this will get put into Tool modules so it's generally
available.

http://codereview.chromium.org/5204/diff/1/2#newcode109
Line 109: contents = contents.replace(undef, definition)
On 2008/09/30 00:56:26, Mark Mentovai wrote:
> How can we be sure that these replacements will be anchored at the beginning
of
> a line?  I can envision this transforming comments inappropriately.  Can we do
a
> regex substitution for this too?

Fair point.  I changed it to a regex.

http://codereview.chromium.org/5204/diff/1/2#newcode117
Line 117: env.Command('$OPEN_VCDIFF_DIR/src/config.h',
On 2008/09/30 00:56:26, Mark Mentovai wrote:
> Refresh my memory about how these work.  If it's target and then dependencies,
> can we do something to ensure that config.h will be rebuilt not only if
> config.h.in changes but also if the list of defines changes?  Make config.h
> depend on the SConscript, maybe?

That's actually already taken care of by the

    Action(AutoConfig, varlist=['DEFINES'])

a few lines below.  That tells SCons that the build output depends not only on
the files involved, and the action involved (it will rebuild if you change the
code in the Python function), but also that it depends on the value of the
DEFINES list.  So it rebuilds if any element in the list changes without having
to put in a more coarse-grained dependency on the entire SConscript file.

http://codereview.chromium.org/5204/diff/1/2#newcode120
Line 120: DEFINES=defines)
On 2008/09/30 00:56:26, Mark Mentovai wrote:
> This generates config.h next to config.h.in, right?  Can we put it somewhere
in
> the build directory instead (and set the include path appropriately?)  I don't
> like littering the source directory, it makes it much harder to clean a build
> and it makes it so much more likely that someone will come along and
> inadvertently add the generated file to the svn repository.

It does what you want, putting the target file in the build directory.  The
build directory is essentially treated like a translucent file system directory
backed by the source directory.  So those paths above are actually in the build
directory, and when it doesn't find config.h.in in the build directory, it uses
the equivalent from the "backing" source directory hierarchy.