Linked list type definition fails compilation

[connorourke]

The type definition:

  TYPE queued_node
      INTEGER  :: node_index
      TYPE(queued_node),POINTER:: next_node
  END TYPE queued_node

produces a f90wrap_*f90 file that produces an error when trying to compile with f2py-f90wrap.

The error is as follows:

Error: Derived type definition of ‘queued_node_ptr_type’ at (1) has already been defined

And is down to the queued_node_ptr_type being defined twice in two of the subroutines:

    use tort_mod, only: queued_node
    implicit none
    type queued_node_ptr_type
        type(queued_node), pointer :: p => NULL()
    end type queued_node_ptr_type
    type queued_node_ptr_type
        type(queued_node), pointer :: p => NULL()
    end type queued_node_ptr_type
    integer, intent(in)   :: this(2)
    type(queued_node_ptr_type) :: this_ptr
    integer, intent(out) :: f90wrap_next_node(2)
    type(queued_node_ptr_type) :: next_node_ptr

    this_ptr = transfer(this, this_ptr)
    next_node_ptr%p => this_ptr%p%next_node
    f90wrap_next_node = transfer(next_node_ptr,f90wrap_next_node)
end subroutine f90wrap_queued_node__get__next_node

subroutine f90wrap_queued_node__set__next_node(this, f90wrap_next_node)
    use tort_mod, only: queued_node
    implicit none
    type queued_node_ptr_type
        type(queued_node), pointer :: p => NULL()
    end type queued_node_ptr_type
    type queued_node_ptr_type
        type(queued_node), pointer :: p => NULL()
    end type queued_node_ptr_type
    integer, intent(in)   :: this(2)
    type(queued_node_ptr_type) :: this_ptr
    integer, intent(in) :: f90wrap_next_node(2)
    type(queued_node_ptr_type) :: next_node_ptr

    this_ptr = transfer(this, this_ptr)
    next_node_ptr = transfer(f90wrap_next_node,next_node_ptr)
    this_ptr%p%next_node = next_node_ptr%p
end subroutine f90wrap_queued_node__set__next_node

If you remove one of these in each subroutine it compiles fine.

Does anyone know how to avoid this issue?

Thanks!

[arunoruto]

I am currently researching a problem of my own and came upon this issue. It could be, that #74 solves the issue, and @connorourke just didn't update the package with the fix.