Archived

This forum has been archived. Please start a new discussion on GitHub.

strange message using slice2javae

Hello I execute the build.xml and it fails, do you know why this message is shown:


generate:
[slice2javae] slice2javae --output-dir "H:\rfranco\Ice\IceEJ-1.0.0\demo\IceE\mi
dp\suscrip con glacier\generated" -I"H:\rfranco\Ice\IceEJ-1.0.0\demo\IceE\midp\s
uscrip con glacier" -IH:\rfranco\Ice\IceEJ-1.0.0\slice "H:\rfranco\Ice\IceEJ-1.0
.0\demo\IceE\midp\suscrip con glacier\AdapterTC65.ice" "H:\rfranco\Ice\IceEJ-1.0
.0\demo\IceE\midp\suscrip con glacier\Router.ice" "H:\rfranco\Ice\IceEJ-1.0.0\de
mo\IceE\midp\suscrip con glacier\Session.ice"
[exec] icecpp.exe: Usage: icecpp.exe [switches] input output
BUILD FAILED
H:\rfranco\Ice\IceEJ-1.0.0\demo\IceE\midp\suscrip con glacier\build.xml:25: exec
returned: 1


thanks

Comments

  • dwayne
    dwayne St. John's, Newfoundland
    Hi,

    I have not yet tried to replicate your problem, but it might be related to the spaces in your directory structure. Could you try using directory names with no spaces to see if this fixes the problem?

    Regards,
    Dwayne
  • Thanks!!

    Thanks a lot!!the problem is fixed, I don´t use spaces never again
  • Spaces in "-I" arguments to slice2java

    The specific problem appears to be with spaces in the "-I" lines; spaces in "--output-path" or whatever aren't an issue. Is there any way this could be changed? At the moment, it's interacting badly for me with the slice2java Ant task's tendency to use absolute rather than relative pathnames ...

    Specifically, I have a slice2java definition like this:
        <target name="ice-java" depends="init">
            <mkdir dir="src/java" />
            <slice2java outputdir="src/java" includepath="ice" >
                <fileset dir="ice" includes="*.ice" />
                <meta value="java:java5" />
            </slice2java>
        </target>
    

    When I'm working in my default Eclipse directory, this gets converted to a command line like this:
    slice2java  --output-dir "C:\Dokumente und Einstellungen\foster\workspace\jast-ice\src\java" -I"C:\Dokumente und Einstellungen\foster\workspace\jast-ice\ice" --meta java:java5 ...
    

    I then get the error message pointed out by the original poster.

    I could move my own working directory to somewhere without spaces, but there's no guarantee that other developers will be configured like that.

    Actually -- and maybe this is a message for a separate bug report -- on Linux I didn't even need the "-I" argument at all; the #includes in the .ice files all resolved each other without any help. I only started seeing this when I tried building my module on Windows.

    MEF
  • benoit
    benoit Rennes, France
    mefoster wrote:
    I could move my own working directory to somewhere without spaces, but there's no guarantee that other developers will be configured like that.

    Yes, we'll look into fixing this.
    Actually -- and maybe this is a message for a separate bug report -- on Linux I didn't even need the "-I" argument at all; the #includes in the .ice files all resolved each other without any help. I only started seeing this when I tried building my module on Windows.

    Hmm, it should be the same on Linux and Windows. Do you have a small test case demonstrating this?

    Cheers,
    Benoit.
  • Hmm, it should be the same on Linux and Windows. Do you have a small test case demonstrating this?

    Turns out it's the same absolute-pathname business. If the slice2java line is like
    slice2java [args] ice\*.ice
    
    then it finds things fine; if it's like
    slice2java [args] "c:\Dokumente und Einstellungen\foster\workspace\jast-ice\ice\*.ice
    
    then #includes don't get resolved across files.

    For the moment, I'm working around this issue by not using the slice2java Ant task, but rather executing slice2java directly from Ant; this lets me specify the command-line syntax with relative pathnames and everything is happy.

    MEF
  • p.s.

    As I suspected: on Linux, both the absolute- and the relative-pathname versions work fine.
  • benoit
    benoit Rennes, France
    Hi,

    I shouldn't matter if you use a relative or absolute path to specify the slice file to compile. Could you post a small test case with some slice files demonstrating this issue?

    Cheers,
    Benoit.
  • Okay, this is weird

    I tried to reproduce this by creating my own files, but for some reason I didn't see the problem, so I'll include the two files that do cause the issue. I think the issue is something slightly different to what I thought, but I'm no longer able to understand it.

    Anyway, the only way I'm able to process "common.ice" is if I'm in the same directory as it and "robot.ice". That is, say they're in a directory "ice-test"; then "slice2java *.ice" from within ice-test works, but "slice2java ice-test\*.ice" from the parent directory results in:
    ice-test\common.ice:4: robot.ice: No such file or directory
    ice-test\\common.ice:30: `jast::robot::Hand' is not defined

    Weird, weird, weird ...

    MEF
  • benoit
    benoit Rennes, France
    Hi,

    Ok, I can reproduce the issue. The icecpp C-preprocessor doesn't behave the same way as on Linux (or cygwin) with the Windows command prompt.

    It looks for files included with #include "..." in the current working directory instead of the directory of the Slice file where the #include is specified. We'll check if this can easily be fixed.

    In the meantime, adding the "-Iice-test" command line option should work.

    Cheers,
    Benoit.
  • Note that we only support #include <> syntax. #include "" syntax is not tested, and might result in undefined behavior.
  • Gotcha!

    Okay, as I understand it, #include <> only searches in the specified include path; no working directories or anything are included. So I just need to specify the path as an "-I" as well and all is good. I'm not a C programmer, so I don't know whether this is how cpp normally works, but at least I understand now so I'm happy. :)
  • Right. #include "..." also tries to do smart things, such as locating the header file in the same directory as the enclosing header file. While this might be convenient for plain C/C++ programming, it only causes headaches when trying to set the right include path in slice2cpp generated code. Just use #include <> and add an appropriate -I statement.
  • To return to my original issue, this does mean that I can't use the "slice2java" Ant task on my current project. This is because:
    • With #include <>, you need to specify an include path
    • When you specify an include path with the Ant task, it gets added to the command line as an absolute path, even if you use a relative path in build.xml
    • There's no guarantee that full paths won't have spaces, especially on Windows
    • Giving an include path with a space currently doesn't work :)
    No hardship, I can just call the command-line executable directly from Ant via "apply", but it's a bit annoying.

    Thanks for your help!

    MEF
  • benoit
    benoit Rennes, France
    Hi,

    I've posted a patch for this problem [thread=2648]here[/thread]. You'll need to recompile the slice2java translator (included with the Ice for C++ source distribution) to try out the fix. I believe this should fix your issue with ant!

    Cheers,
    Benoit.