Hi William,
I've just opened a pull request for this:
https://github.com/swig/swig/pull/46
Cheers,
Karl
On 30 April 2013 08:56, William S Fulton <wsf@...> wrote:
> Thanks for the diagnosis. Yes, let's change the name of the TARGET to
> swigexample. I'll do it in the next couple of days if no-one beats me to it.
>
> William
>
>
> On 29/04/13 11:31, Karl Wette wrote:
>
>> Hi William,
>>
>> I think the only reliable way around this would be to change the output
>> Octave module name in Examples/octave/ to something else, e.g.
>> swigexample. I think you'd just need to change the TARGET name in the
>> Makefiles and then edit the runme.m scripts.
>>
>> Cheers,
>> Karl
>>
>>
>> On 27 April 2013 19:55, William S Fulton <wsf@...
>> <mailto:wsf@...**uk <wsf@...>>> wrote:
>>
>>
>> Can the Octave experts let me know how to get rid of these warnings
>> which are appearing using octave 3.6.4:
>>
>> checking Examples/octave/callback
>> warning: function ./example.oct shadows a core library function
>> checking Examples/octave/class
>> warning: function ./example.oct shadows a core library function
>>
>> I'm not sure what the name of the function it is shadowing, can we
>> rename the function or suppress the warning?
>>
>> William
>>
>> ------------------------------**------------------------------**
>> ------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt!
>> http://p.sf.net/sfu/newrelic_**d2d_apr<http://p.sf.net/sfu/newrelic_d2d_apr&gt;
>> ______________________________**_________________
>> Swig-devel mailing list
>> Swig-devel@...**net <Swig-devel@...>
>> <mailto:Swig-devel@...**sourceforge.net<Swig-devel@...>
>> >
>> https://lists.sourceforge.net/**lists/listinfo/swig-devel<https://lists.sourceforge.net/lists/listinfo/swig-devel&gt;
>>
>>
>>
>

On 4 May 2013 17:46, Geert Janssens <info@...> wrote:
> **
>
> For all I'll write below, keep in mind that my autoconf knowledge is
> fairly limited...
>
>
>
> I'm surprised that pkg-config is causing that much trouble. It's used by
> the guile sources to build guile. So I would expect any system that ships
> guile also has a compatible version of pkg-config. (I'm not a Guile core
> dev, but I have worked on getting guile to compile on Windows for the
> GnuCash project).
>
>
>
> I suspect the problems arise from the fact that PGK_CONFIG is inside an
> if/then construct. I found references that this might cause problems (1).
>
>
>
> I have rewritten the code a bit to use AS_IF instead of plain
> if/then/else, as suggested on that page. You can find my patch here:
>
> https://github.com/gjanssens/swig/tree/guile_config_tmp
>
>
>
> Can you try this and see if the expansion issues go away ? The patch is
> not complete yet, but I'd like to know if it's worth continuing in this
> direction.
>
>
No real progress, the error message is equally obscure.
+ autoconf
configure:8954: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
BTW, you can test this by just removing pkg.m4 from your installation (like
old versions of pkg-config which don't install any pkg.m4 file). Probably
we can just put in a copy of pkg.m4 into Tools/config to solve this
problem, but we'd probably have to check that the include paths given to
aclocal and ensure our pkg.m4 doesn't override the system's pkg.m4.
>
>
> On Saturday 04 May 2013 00:20:54 William S Fulton wrote:
>
> >
>
> > Some questions:
>
> > - Why was guile-config dropped? It still seems to work okay.
>
> It wasn't working properly when I tried it for guile 2. I'm smarter now
> than I was when I started this and meanwhile I have found it was mostly
> used improperly already in the existing configure script. The way guile was
> installed before 2.0, this didn't cause any issues. But for 2.0 it broke
> configure. Given that guile in its documentation recommends using
> pkg-config (2) and not knowing how to invoke guile-config properly for
> guile 2.0, I decided to go try pkg-config. The guile-config tool is still
> there in guile 2.0, but I'm not sure if it will remain so.
>
>
>
> > - Why isn't PKG_PROG_PKG_CONFIG() used instead of AC_PATH_PROG to look
>
> > for pkg config? Surely that macro will know how to look for the
>
> > appropriately named pkg config program. Using it (when a min version is
>
> > given as a parameter) will also give a much more obvious error as to
>
> > what is wrong if the autoconf macros are not available.
>
> This shows my limited autoconf knowledge. The test for pkg-config was
> copied from the GnuCash project. I now think the GnuCash config file may be
> due for some updates.
>
> > - Shouldn't we still be using guile-config if pkg-config does not find
>
> > guile. It looks like it provides the same info we require and can
>
> > probably be mapped to the same GUILExxx variables needed for the
> makefiles.
>
> >
>
> In my most recent patch, I have used the autoconf macros provided by guile
> (which internally depend on pkg-config).
>
> For guile 1.8, the GUILE_FLAGS macro will call guile-config behind the
> scenes so in the end with guile 1.8 the relevant information comes from the
> same source. For guile 2.0 this is no longer true. Clearly the guile
> developers are moving away from guile-config in favour of pkg-config.
>
>
>
> So in my opinion getting the pkg-based configuration working properly will
> be better in the long term.
>
>
>
> By the way, I won't be available from Sunday till Friday, so future
> reactions may come only after that.
>
>
>
> Geert
>
>
>
> (1) For example in section 3.4 on this page:
>
>
> http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/pkg_check_modules.html
>
> (2)
> http://www.gnu.org/software/guile/manual/guile.html#Autoconf-Background
>
Maybe Guile and GnuCash can get away with having pkg-config properly
installed, but SWIG is about a whole lot more languages than Guile and I
need it to work on a wider set of configurations. As depending on
pkg-config can easily break the autogen.sh stage, I'm going to remove the
pkg-config dependency and go back to using guile-config. Maybe it will have
problems in the long term, but correctly getting guile detected is not that
important. For now, it works and doesn't have any negative side effects on
old machines for developers where pkg-config is out of date. The most
important thing is for configure to finish successfully so that folk can
build SWIG. Of secondary importance is getting a perfect target language
detection working, especially given the values can be provided with the
--with-guile-xxxx options. I have hence rewritten configure.ac to use
guile-config.
Hope you enjoy your break and when you come back, please try it out and I
would appreciate it if you could find a way to set the GUILE_SCM_INTERFACE
flag in some intelligent way, perhaps by running some guile code to detect
scm over gh or using 'guile-config info guileversion' or something else in
guile-config that is still supported in the newer versions. Probably you
need something like GUILE_MODULE_CHECK in guile.m4. I notice that guile-1.6
doesn't work, even though from what I understand it does have scm support.
Perhaps in that case we just check for 1.8 or later.
William

On 03/05/13 17:56, Geert Janssens wrote:
> On Wednesday 01 May 2013 17:30:59 William S Fulton wrote:
>
> > On 01/05/13 11:39, Geert Janssens wrote:
>
> > > The multimap example is an exception to the above. It is set up to use
>
> > > the test suite mechanism of running. Unfortunately there was also a bug
>
> > > in the runtime script that resulted in a runtime error. I have fixed
>
> > > this now, and adapted the Makefiles slightly to run the example
>
> > > automatically when making it.
>
> >
>
> > Great, I have also fixed the 64 bit problem in the example now that
> it runs.
>
> > > If you want all the examples to work the same way that is certainly
>
> > > possible. I'm just not sure what the best strategy is (augmenting the
>
> > > guile binary or loading the wrapped code at runtime). And it may
> also be
>
> > > nice to demonstrate both forms for interested users.
>
> >
>
> > Let's keep to both approaches. Once you have got them all working, my
>
> > intention is to put the running of these into the Examples/Makefile to
>
> > be consistent with all the other languages. See guile_run target in that
>
> > Makefile. An equivalent called something like guile_run_augmented can be
>
> > added to run the augmented interpreter. Is 'augmented' the proper name
>
> > for this kind of approach?
>
> >
>
> I'm not sure. This is new territory for me as well. I just borrowed this
> name from Lib/guile/guilemain.i
>
> The initial comment in there talks about generating a user augmented guile.
>
> So I guess that name can be used for this technique.
>
I got the std_vector and multivalue examples running using the
dynamic-link approach.
My latest changes also get the guile test-suite and examples working
correctly on Cygwin. With respect to the examples, the only remaining
thing you could help out with for now is the 'port' and 'class' example,
then Guile will be sufficiently ready for release as far as I'm
concerned although I'll tidy up the Makefiles a bit more.
William