Hi Volodya--
Thanks for the reply and suggestion.
> > Umm... I understand *how* Subversion works. The problem is trying to
> > make Subversion checkouts work with an already well-established model
> > for the interaction of build tools and (other) source code management
> > system. Just saying, "There is no need," ignores certain tough end
> > cases that I, as a build tool designer, must think through and figure
> > out how to handle so that, at a minimum, the tool doesn't cause any
> > damage.
>
> I think it would be better if you explain how VC tool interaction is supposed
> to work in SCons. For example, I can't imagine how per-file checkout can
> be specified/used.
>
> I can easily imagine the build tool integration on project level (i.e. when
> building Subversion, APR and APR-utils are fetched automatically). OTOH,
> there's 'svn:externals' mechanism which is *very* good for such kind of thing.
> It allows, when checking out a project, to grab other projects it requires.
>
> So, can you outline primary use cases which are needed, or point to some
> SCons docs which describe it.
Okay, good idea.
Here's a sample of how I *thought* this might work for a local
Subversion repository. Given the following in an SConstruct file (the
SCons equivalent of a Makefile):
env = Environment()
svn = env.Subversion('file:///usr/Subversion/project')
env.SourceCode('.', svn)
SConscript('sub/SConscript', "env")
env.Program('sub/foo', ['sub/f1.c'])
The "env.SourceCode()" line tells SCons that anything under the current
directory, if it doesn't already exist locally, can probably be found by
checking out (all or part of) the source from the specified Subversion
repository.
Now, I can make SCons check out the directory, not the individual file,
so if for some reason the "sub" subdirectory hasn't already been checked
out, the output from a run with the above configuration might look like:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
svn co -N file:///usr/Subversion/project/sub
A sub/f1.c
A sub/SConscript
Checked out revision 1.
cc -c -o sub/f1.o sub/f1.c
cc -o sub/foo sub/f1.o
scons: done building targets.
But because of the way the walk of the dependency tree is done, SCons
(or, probably, any other build tool) can't realize that the directory
needs to be checked out until it goes to try to build the sub/f1.o
object file and finds out that the sub/f1.c source file isn't there.
Now suppose that after I had checked out the above revision, but before
I built the program, someone has checked in a change that adds a new
sub/f2.c source file. In this case, sub/f1.c would already exist, but
sub/f2.c would not. SCons would detect that sub/f2.c is missing and,
based on the "env.Subversion()" specification in its input file, try to
create sub/f2.c from the Subversion repository. I think the right thing
to do here is detect the sub/.svn directory and issue an update, not a
checkout, in which case I *think* the output would look something like:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
svn up -N file:///usr/Subversion/project/sub
A sub/f2.c
Checked out revision 2.
cc -c -o sub/f2.o sub/f2.c
cc -o sub/foo sub/f1.o sub/f2.o
scons: done building targets.
Am I on track so far?
Now, one side effect of having to update the whole directory is that it
might update something that's already been visited in the dependency
walk. For example, if I'd not yet built anything in that subdirectory,
and in revision 2 someone modified the sub/f1.c file *and* has added
a new sub/f2.c file, then SCons would likely not detect the missing
sub/f2.c file and the need to update until after it had built sub/f1.o.
In the most straightforward implementation, that could cause the
following problem:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cc -c -o sub/f1.o sub/f1.c
svn up -N file:///usr/Subversion/project/sub
U sub/f1.c
A sub/f2.c
Checked out revision 2.
cc -c -o sub/f2.o sub/f2.c
cc -o sub/foo sub/f1.o sub/f2.o
scons: done building targets.
Uh-oh, I'd have now created an incorrect program, because sub/f1.c has
been updated after I've already compiled it. This is where I start to
wonder if Subversion and automatic build tool checkouts just don't work
well together and I should drop trying to support Subversion.
Another way I might solve the above problem would be to create a
dependency on the directory as well as the source file. This would try
to make sure that no source file from a directory gets used before *all*
the source files in a directory are present, so I could issue the "svn
co" or "svn up" before anything depending on them gets built. But this
could be really tricky, because a source file in one subdirectory could
be used anywhere in the tree, not just local to that subdirectory.
It's cases like this that are making me turn to the Subversion community
to find out if I'm overlooking some clever way of dealing with
Subversion that might make this doable. But I'm beginning to wonder if
this really is a case of a square peg meeting a round hole...?
--SK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 24 15:06:02 2003