[Insight-users] Re: itk java wrapper on cygwin problem (Progress)

[Michael Bell]

SwigInc.txt is being generated from SwigInc.txt.in, which has the
extra carriage return character. I suspect this is a problem because I
am using the cygwin recommended unix files, but this file is a dos
file. If I dos2unix SwigInc.txt.in and make, this error goes away, and
all of the SwigIn.txt files are correct. If I run dos2unix on the
entire Wrapping directory, many problems are fixed.

Which shows the next issue:
javac does not understand cygwin paths. This issue can be fixed using cygpath.

Which shows the next problem:
javac VXLNumericsJava.java
cannot resolve symbol itkbase

I haven't solved that problem, but I am certain it would reveal more.

It's pretty clear that no one is maintaining the wrappers with cygwin.
Please make this clear somewhere in the documentation so the next
person does not waste weeks on this, as I have.

So, we know that VS8 does not work. Cygwin does not work. What does
work on Windows? I can change compilers, but I can't spend time
hunting for a platform that does work. Please advise.

thanks,
michael




On 7/17/06, Michael Bell <michael.bell at acm.org> wrote:
> ITK people,
>
> I have made some progress tracking down this error:
> wrap_vnl_matrix.xml from gccxml_cc1plus:
>  error: too many filenames given.  Type gccxml_cc1plus --help for usage
> make[2]: *** [Wrapping/CSwig/VXLNumerics/wrap_vnl_matrix.xml] Error 1
>
> This is the operation that fails (paths shortened for readability):
> gccxml -fxml-start=_cable_ -fxml=wrap_vnl_matrix.xml
> --gccxml-gcc-options SwigInc.txt -DCSWIG -DCABLE_CONFIGURATION
> wrap_vnl_matrix.cxx
>
> SwigInc.txt contains a list of include paths:
> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Build_Cygwin
> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/Algorithms
> ...
> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/BasicFilters
> ^M
>
> Then, it has the ^M character at the end. If I remove this character,
> the xml file appears to be created correctly. Does anyone know where
> this is being created, or why, or how I can prevent it? Is this an ITK
> problem, or a CableSwig problem?
>
> Please, I'm obviously willing to do the leg work, but it will take me
> 10 times as long to figure this out than if an ITK developer would
> step up and help. I've already shown that I was not the first person
> to deal with this problem, and there are likely others who have not
> said anything.
>
> thanks,
> michael
>
>
> --
> michael.bell at acm.org
>


-- 
michael.bell at acm.org