Re: [Swig-user] swigwin 1.3.37 python problem

[Haoyu B. <div...@gm...>]

On Thu, Jan 15, 2009 at 9:21 PM, Noel O'Boyle <bao...@gm...> wrote:
> 2009/1/15 Haoyu Bai <div...@gm...>:
>> On Thu, Jan 15, 2009 at 6:13 PM, Noel O'Boyle <bao...@gm...> wrote:
>>> 2009/1/14 William S Fulton <ws...@fu...>:
>>>> Noel O'Boyle wrote:
>>>>>
>>>>> 2009/1/14 Noel O'Boyle <bao...@gm...>:
>>>>>>
>>>>>> 2009/1/14 Haoyu Bai <div...@gm...>:
>>>>>>>
>>>>>>> On Wed, Jan 14, 2009 at 5:00 AM, Noel O'Boyle <bao...@gm...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> I've been eagerly awaiting the recent Swig release with support for
>>>>>>>> Python 3.0.
>>>>>>>>
>>>>>>>> However, I have been testing the swigwin binary on Windows and while
>>>>>>>> the .cpp file is generated correctly (as far as I can tell - it
>>>>>>>> compiles fine anyway), the corresponding Python module is not created.
>>>>>>>>
>>>>>>>> I've just doublechecked again - swigwin 1.3.36 works fine, but not
>>>>>>>> 1.3.37. Any idea what's going on?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>  Noel
>>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> How did you do to create the module? You mean the .py wrapper is not
>>>>>>> created, or the .pyd file not produced?
>>>>>>>
>>>>>>> -- Haoyu Bai
>>>>>>
>>>>>> The .py wrapper is not created. I call swig as follows:
>>>>>> swig -c++ -python -I"../../src"  -I"../../include" -I".." -o
>>>>>> "openbabel_wrap.cpp" openbabel-python.i
>>>>>>
>>>>>> - Noel
>>>>>>
>>>>>
>>>>> Sorry, my mistake. The openbabel.py is now created in a different
>>>>> location - the location of the interface file. Problem solved.
>>>>>
>>>>
>>>> Noel, there is a change in that you should no longer use the include paths
>>>> to find the input file, so the path to the .i file must be specified. The
>>>> behaviour is then like c/c++ compilers as they don't use the include path to
>>>> find the input file. You get a warning if the .i file can only be found by
>>>> searching the include path:
>>>>
>>>> SWIG:1: Warning(125): Use of the include path to find the input file is
>>>> deprecated and will not work with ccache. Please include the path when
>>>> specifying the input file.
>>>>
>>>> But given your command line above, the openbabel.py file should be output to
>>>> the same location (assuming you have kept the commandline the same for
>>>> 1.3.36 and 1.3.37). Possibly you changed the commandline option for 1.3.37,
>>>> if not I'd be interested to understand exactly what you did as the behaviour
>>>> would have changed unintentionally.
>>>>
>>>> William
>>>
>>> I'm afraid I over-simplified my command line, but it's true that there
>>> is a change in behaviour between 1.3.36 and 1.3.37 that's not
>>> described in the release notes and doesn't appear in the docs.
>>>
>>> I'm running Swig inside the MSVC++ environment with the following command line:
>>>
>>> swig -c++ -python -I"../../src"  -I"../../include" -I".." -o
>>> "$(ProjectDir)\$(InputName)_wrap.cpp" "$(InputPath)"
>>>
>>> which is translated by MSVC++ to:
>>>
>>> swig -c++ -python -I"../../src"  -I"../../include" -I".." -o
>>> "c:\Tools\OpenBabel\ob-22x\windows-vc2005\OBPythonOBF\\openbabel-python_wrap.cpp"
>>> "c:\Tools\OpenBabel\ob-22x\scripts\openbabel-python.i"
>>>
>>> The path to the interface file is given explicitly, not found using
>>> the include path. With 1.3.36, openbabel.py is written to
>>> c:\Tools\OpenBabel\ob-22x\windows-vc2005\OBPythonOBF\\openbabel.py.
>>> This is in agreement with the Swig docs under 5.1.2:
>>>
>>> "Many target languages will also generate proxy class files in the
>>> target language. The default output directory for these language
>>> specific files is the same directory as the generated C/C++ file. This
>>> can be modified using the -outdir option."
>>>
>>> With 1.3.37, openbabel.py is written to
>>> c:\Tools\OpenBabel\ob-22x\scripts\openbabel.py instead.
>>>
>>> To get around this, I needed to add "-outdir ." to the command-line;
>>> then the original behaviour is reproduced. As a side issue, I note
>>> that Swig cannot handle a PATH containing spaces in the value for
>>> outdir (even if enclosed in quotation marks) even though this is no
>>> problem for the "-o" switch.
>>>
>>> Hope this helps clarify,
>>>
>>> - Noel
>>>
>>
>> Hi,
>>
>> I tried on my Linux and can't reproduce this.
>>
>> With the SVN build of SWIG, I have run this:
>>
>>  [bhy@home ../trunk/Examples/python]$ ../../preinst-swig -python -c++
>> -o class/example_wrap.cxx class/example.i
>>
>> And then everything generated in the class/ dir. Maybe this is due to
>> SWIG haven't deal windows dir separator "\" properly?
>>
>> Noel could you try to change the "\" to "/"?
>>
>> -- Haoyu Bai
>
> Your example is not quite the same - you have the interface file and
> the .cpp file in the same directory so you won't see any effect. If
> you move the interface file to a different directory, e.g.
> newclass/example.i, you should see the problem (I hope).
>
> I can test changing "\" to "/", but I note that the same problem was
> identified and fixed (by specifying outdir) in our Linux build.
>
> Noel
>

Hi

Sorry I misunderstood it. And I can reproduce it now.

William, this maybe a side effect of your SVN commit #10947:

2008-11-24: wsfulton
           Add -outcurrentdir option. This sets the default output
directory to the current
           directory instead of the path specified by the input file.
This option enables
           behaviour similar to c/c++ compilers. Note that this
controls the output directory,
           but only in the absence of the -o and/or -outdir options.

-- Haoyu Bai