On 12/17/05, Philip Martin <philip@codematters.co.uk> wrote:
> >> On 12/16/05, Jani Averbach <jaa@jaa.iki.fi> wrote:
> >>> On 2005-12-16 20:40+0000, Philip Martin wrote:
> >>> > > Please see: http://svn.haxx.se/dev/archive-2005-11/1324.shtml
> >>> > So it fails shortly after r17497 "Always generate SWIG/C files and
> >>> > SWIG headers in the source directory", are you using a VPATH build?
> >>> Yes, the test system is using vpath setup.
> >> I've committed a fix for this bug in r17818. Does this help?
> > Yes, that works. 'make clean-swig' doesn't delete the symlinks but
> > that doesn't seem to cause a problem.
> What's not clear from the original thread is why the generated files
> should go in the source directory instead of the build directory. The
> thread includes some arguments about why it is acceptable, but not why
> it is necessary--it looks like a rather drastic side-effect of a bug
> fix.
>
> The build system appears to have all the bits necessary to allow the
> build directory to be used. With the patch below I can run autogen
> with or without --release and the VPATH build puts the generated files
> in the build directory, no symlinking or copying is necessary.
Really? That's fantastic! We switched Subversion to generate
SWIG-related files in the source directory because we wanted to get
rid of the complex, confusing, and messy code for copying files from
the source directory to the build directory when you build the SWIG
bindings in a VPATH setup. If we can generate SWIG files in the build
directory without resorting to complex code, then we should definitely
do so! It looks like you've discovered a way to do this: great!
I've included some comments on your patch below.
> swig-pl: $(swig-pl_DEPS)
> - if test "$(SWIG_PL_DIR)" != "$(SWIG_PL_SRC_DIR)"; then \
> - ln -sf $(SWIG_PL_SRC_DIR)/native/*.c $(SWIG_PL_DIR)/native; \
> - fi
> cd $(SWIG_PL_DIR)/native; $(MAKE)
If we're in a release-mode VPATH setup, we need to copy or symlink the
Perl ".c" files to the build directory. I see you've removed the code
for doing this. Instead we should adjust it so that it is only used
when $RELEASE_MODE is enabled. (Without this fix, the Perl bindings
don't compile in a release-mode VPATH setup)
> -copy-swig-py: autogen-swig-py $(SWIG_PY_DIR)/libsvn
> - @cp -pf $(SWIG_PY_SRC_DIR)/*.py $(SWIG_PY_DIR)/libsvn
> +swig-py: autogen-swig-py
>
> -swig-py: autogen-swig-py copy-swig-py
> -
Without the copy-swig-py rule, check-swig-py fails (in both VPATH and
normal setups) due to missing python files. If we bring it back, we'll
need to adjust it to copy the appropriate files from the source or
build directories, depending on whether we're in release mode.
> Perhaps I am abusing the source_generated stuff, I'm not quite
> sure what's intended for that flag.
It looks like the 'source_generated' flag indicates whether the source
code is generated in the build directory. If this is set to zero, then
we look in the source directory instead. It looks like you are using
the flag correctly.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Received on Sun Dec 18 03:09:56 2005