Re: [Swig-devel] swig_and_compile_external

[William S F. <ws...@fu...>]

On 24/04/13 15:33, Geert Janssens wrote:
> On Tuesday 23 April 2013 23:44:57 William S Fulton wrote:
>
>  > On 20/04/13 14:00, Geert Janssens wrote:
>
>  > > Guile has one testcase labeled as an external test. Compared to the
>
>  > > other tests, this uses a different path in the makefiles: it uses
>
>  > > swig_and_compile_external.
>
>  > >
>
>  > > Looking through the rest of the swig modules, I find only the chicken
>
>  > > module to use this as well (the chicken module looks to be very similar
>
>  > > to the guile module in many ways).
>
>  > >
>
>  > > Unfortunately, this test is failing (the external cxx file is not
>
>  > > found). As I don't find tests in any of the more mainstream modules
>
>  > > (like python, perl,...) using swig_and_compile_external, I'm
> starting to
>
>  > > wonder if perhaps this is a deprecated swig feature, to be replaced
> with
>
>  > > something else ?
>
>  > >
>
>  > > So what's the story behind swig_and_compile_external ? I didn't find
>
>  > > much by seaching the web.
>
>  >
>
>  > Looks like the testcase got renamed, but not all of it. I've committed a
>
>  > patch on master to fix.
>
>  >
>
>  > William
>
> Thanks for the fix. I had to fix a bug I introduce myself before the
> test ran on my branch. That is done now.
>
> One caveat: the external test will only work when testing in-tree (ie
> use source dir as build dir). Out-of-tree configure and test will fail.
> I have spent the better part of the day trying to fix this, but was not
> successful.
>
> The cause of the failure is that in case of an out-of-tree build the
> external cxx file is not in the same directory as the generated wrap.cxx
> file. As a result make complains that guile_ext_test_external.cxx can't
> be found.
>
> I tried several things to fix it:
>
> 1. Adding $(srcdir) to the filename in common.mk (in rule
> swig_and_compile_external). The compile step then works, but the link
> step complains that $(srcdir)/guile_ext_test_external.o can't be found.
> Obviously, because it ends up in the build dir.
>
> 2. Played with VPATH, but couldn't get it to work.
>
> 3. added CXXSRCS as requirement to build guile_cpp, no difference.
>
> Two possible solutions I haven't tested yet:
>
> - at compile time, create a softlink from the build directory to
> $(srcdir)/guile_ext_test_external.cxx (only when building out-of-tree
> obviously).
>
> - make a separate make variable EXT_CXXSRCS to hold all the external
> source files. These sources could be added with the proper $(srcdir)
> prefix. The variable then has to be added to OBJS, but with a different
> filtering (ie the srcdir should be removed in addition to changing the
> suffix). I'm not sure if this is possible/easy.
>
> For now I'll leave that as an exercise for later. I have more pressing
> matters to attend to.
No problem, there are a few rough edges around running the test-suite in 
out of source builds and I'll sort those out one day. It used to work 
fine. I hardly ever test this though, so could have bit rotted. My plan 
is to use out of source builds on Travis when they are up and running 
again to make sure we don't regress. However, in order to get that 
working I need to change the way a couple of files get generated into 
the Lib directory. I also need to move the examples to use Makefile.in 
instead of Makefile. In fact I have started the move towards this by 
recently making all the example makefiles almost identical. One thing I 
havn't quite found a solution is this:

There are loads (over 400) Examples/xxxx/Makefile files. If I convert 
all of these to Makefile.in, I won't be happy with the configure step 
which will display one line for each Makefile.in as I feel that is 
unnecessarily verbose. So I'm looking for a solution if anyone has any 
suggestions that will work. Something like having one Makefile.in for 
each target language and some way to invoke that in an out of source 
build... I'm not sure this is possible, but would love to be proved wrong.

William