Re: [Swig-devel] Python test case with packages

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

On 05/01/13 12:23, Paweł Tomulik wrote:
> On 05.01.2013 12:48, William S Fulton wrote:
>>
>> On 5 January 2013 00:31, Paweł Tomulik <pto...@me...
>> <mailto:pto...@me...>> wrote:
>>
>>     Hi all,
>>
>>     I've faced some bugs in swig that make me unable to progress with
>>     one of my projects and I'm currently working on patches (two of
>>     them are already proposed as pull requests on github).
>>
>>     For one bug (https://sourceforge.net/p/swig/bugs/1297/),
>>     the test cases consist of few %module's, and the resultant
>>     python code is structured such that it contains python modules
>>     within packages and subpackages.
>>
>>     For example, one of my current mini-projects used to replicate the bug
>>     has structure:
>>
>>     case/
>>     | runme.py
>>     |
>>     + P1/
>>        |__init__.py
>>        | foo.hpp
>>        | Foo_Mod.py
>>     |
>>        + S1/
>>            __init__.py
>>            bar.hpp
>>            Bar_Mod.i
>>
>>     Is there a way to map such mini-project to a test case that could
>>     fit to the
>>     swig's testing framework (under Examples/test-suite/.. or in other
>>     right
>>     place) ?
>>
>> This is a little unusual.
>
> Yes, but I must use directories/subdirectories to fully replicate this bug.
>
>> There are some %import testcases you could look at, but they use one
>> directory for the inputs which is what we have managed to do up till
>> now. These are the 'MULTI_CPP_TEST_CASES" in common.mk
>> <http://common.mk> and correlate to:
>>
>> $ grep -l "%import" *
>> clientdata_prop_b.i
>> import_nomodule.i
>> imports_a.i
>> imports_b.i
>> import_stl_b.i
>> mod_b.i
>> multi_import_a.i
>> packageoption_c.i
>> template_typedef_import.i
>>
>> Note that the header files they import are prefixed by the testcase
>> name by convention.
>>
>> There is also inctest.i which is the only testcase that uses a
>> directory hierarchy like you need:
>>
>> $ find testdir
>> testdir
>> testdir/test.i
>> testdir/subdir1
>> testdir/subdir1/subinc1.i
>> testdir/subdir1/hello.i
>> testdir/subdir1/imports.i
>> testdir/subdir2
>> testdir/subdir2/hello.i
>> testdir/subdir2/imports.i
>> testdir/subdir2/subinc2.i
>>
>> I suggest we change testdir to have testcase names as the first
>> subdirectory so change testinc to have:
>>
>> testdir
>> testdir/inctest/test.i
>> testdir/inctest/subdir1
>> testdir/inctest/subdir1/subinc1.i
>> testdir/inctest/subdir1/hello.i
>> testdir/inctest/subdir1/imports.i
>> testdir/inctest/subdir2
>> testdir/inctest/subdir2/hello.i
>> testdir/inctest/subdir2/imports.i
>> testdir/inctest/subdir2/subinc2.i
>>
>> then you can create a new directory named after your testcase under
>> testdir.
>
> This gives me some idea. However, it seems like the test cases,  as
> above, will be run
> for each supported language (?). My test should be run only under python
> - the issue
> is python specific. Actually I've prepared test cases and under
> 'Examples/python'
> so I have currently example/test directories:
>
> Examples/python/import_from_init/
> Examples/python/import_from_init2/
> Examples/python/import_from_init3/
> Examples/python/import_same_modnames/
> Examples/python/import_same_modnames2/
>
> with packages/subdirs within. You may find the relevant commit at:
>
> https://github.com/ptomulik/swig/commit/973622e1df1765c2e28a8889b02be9cdc5d8f7a2
>
> This was the simplest way for me, but I understand that 'Examples/' are
> not the best place
> to keep test cases that are related to bugs/issues.
>
> Can I just leave it as is for the moment and open a new issue to mark
> that these test cases
> should be moved to a better place? This way, the #1297 could be fixed
> and tested now, and
> the tests could be moved to a right place after the test-suite dir would
> be able to accept test
> cases consisting of dirs/subdirs?
You should be able to move that directory structure as I suggested into 
the test-suite. The test-suite can handle python specific tests too. 
Just prefix the test name with 'python_' and add it into Makefile.in 
instead of common.mk.

William