[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: swig: srcdir vs. blddir (was Re: 1.3.0-rc3 tarballs up for testing/signing)

From: David James <james_at_cs.toronto.edu>
Date: 2005-11-23 09:13:18 CET

On 11/22/05, Eric Gillespie <epg@pretzelnet.org> wrote:
> Max Bowsher <maxb1@ukf.net> writes:
> > The interesting wrinkle here is that, SWIG files which can be shipped in
> > a tarball, or generated during the build, can be in the srcdir OR the
> > blddir, not always one or the other.
> That's not very wrinkly, but actually quite common. Files that
> ship in the distfile have to work from srcdir, so why have them
> also work from blddir? Just build them into srcdir instead of
> blddir.
> [snip convincing argument for generating SWIG code in the src dir]
Great idea, Eric! I'm convinced. It's not only better to generate our
SWIG code in the source directory, but also much easier.

I couldn't wait, so I attached a patch which demonstrates your idea.
Let me know if you have any suggestions or feedback.

We still have some logic in Makefile.in for copying Python files from
the source directory to the build directory under the copy-swig-py. I
haven't removed this code yet, but it might be a good idea for us to
do so, as soon as we update our install and test suite targets to use
the Python files from the source directory.

Always generate SWIG/C files in the source directory.

* build/generator/gen_make.py
  (write): Generate SWIG/C files in source directory. Don't copy SWIG/C
  files from the source directory to the build directory.

* build/generator/gen_base.py
  (TargetSWIG.add_dependencies): Read generate SWIG/C dependencies from
  the source directory.

Suggested by: epg




David James -- http://www.cs.toronto.edu/~james

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Wed Nov 23 09:14:12 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.