Archived

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

slice2cpp constructs absolute paths for include

Hi!

I'm trying to port a project from Ice 3.2 to Ice 3.3. But the slice2cpp is giving me problems. Consulting the documentation and looking for existing threads in this forum did not bring up any answers.

I attached all files.

I have multiple slices which include each other. The inclusion is translated into absolute paths by slice2cpp. But those paths don't refer to the correct location. To break it down take these as examples:

//A.ice
module mymodule {
sequence<string> StringSequence;
};

//B.ice
#include "A.ice"
module mymodule {
interface TestInterface {
void setOptions(StringSequence options);
};
};

All my efforts to construct a sensible output from B.ice with slice2cpp resulted in a header that includes an absolute path to "A.h". The commands I tried are:

slice2cpp --output-dir out B.ice
slice2cpp --output-dir out -I. B.ice
slice2cpp --output-dir out -I. *.ice
slice2cpp --output-dir out -IC:\Develop\IceSupportRequest\Ice3.3slice2cpp B.ice

Here is a sample of the command line:
//////////////////////////////BEGIN Cmdline
C:\Develop\IceSupportRequest\Ice3.3slice2cpp>\Programme\ZeroC\Ice-3.3.0\bin\slice2cpp.exe -v
3.3.0

C:\Develop\IceSupportRequest\Ice3.3slice2cpp>\Programme\ZeroC\Ice-3.3.0\bin\slice2cpp.exe --output-dir out -I. B.ice
C:/Develop/IceSupportRequest/Ice3.3slice2cpp/B.ice:0: warning: Unknown encoding: de

C:\Develop\IceSupportRequest\Ice3.3slice2cpp>
//////////////////////////////END Cmdline

The resulting header "B.h" includes:
//////////////////////////////BEGIN B.h
#include <Ice/Incoming.h>
#include <Ice/Direct.h>
#include <Ice/StreamF.h>
#include <C:/Develop/IceSupportRequest/Ice3.3slice2cpp/A.h>
#include <Ice/UndefSysMacros.h>
//////////////////////////////END

The header is in the output-dir, of course! I can't see what I did wrong. Previous versions of slice2cpp worked fine.

I tried this on WindowsXP using the binary package I downloaded (MSI Installer). And I also tried this using the 3.3 source distribution on linux which I compiled myself. Both versions of slice2cpp produce the same output, namely an absolute path that doesn't even refer to the output dir.

In the current state, Ice 3.3 does not integrate into the build system I use, because the build system is designed to use separate source and build directories. I hope someone can resolve this issue.

Regards,
Frank

Comments

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

    Thanks for the report, we will look into it further. In the meantime the following should work:

    In B.ice, change
    #include "A.ice"
    

    to
    #include <A.ice>
    

    and then compile using
    slice2cpp --output-dir out -I. B.ice
    

    Dwayne
  • When I encountered similar problems a while ago, I'm pretty sure was told that #include <file> was the only version that was guaranteed to work, and that #include "file" wasn't supported. (I can't find that thread at the moment, but I know I came across this before ...)

    MEF
  • Section 4.4.3 of the manual says that double quotes have different behavior on different operating systems and recommends to use angle brackets.

    Cheers,

    Michi.
  • Hi!

    I never thought changing include statements from "A.ice" to <A.ice> would make any difference in this regard. But actually they do have a different meaning.

    Anyways on my linux machine I get the same wrong result. B.ice:
    #ifndef MY_MODULE_B_ICE
    #define MY_MODULE_B_ICE
    
    #include <A.ice>
    
    module mymodule {
            interface TestInterface {
                    void setOptions(StringSequence options);
            };
    };
    
    #endif
    

    my command line:
    1 for bloodymir@newton:~/develop/p3solutions/RatRunnerV7/Slices
    $LD_LIBRARY_PATH=/home/bloodymir/develop/Ice-3.3.0/lib/ /home/bloodymir/develop/Ice-3.3.0/bin/slice2cpp -I. --output-dir ../build/Slices/debug/ice-3.3.0/ Gui.ice
    Gui.ice:1: warning: Converted [CR+LF] to [LF]
        #ifndef RATRUNNER_ICE_GUI_ICE
    

    partial content of out/B.h:
    // Ice version 3.3.0
    // Generated from file `B.ice'
    
    #ifndef __out_B_h__
    #define __out_B_h__
    
    #include <Ice/LocalObjectF.h>
    #include <Ice/ProxyF.h>
    #include <Ice/ObjectF.h>
    #include <Ice/Exception.h>
    #include <Ice/LocalObject.h>
    #include <Ice/Proxy.h>
    #include <Ice/Object.h>
    #include <Ice/Outgoing.h>
    #include <Ice/Incoming.h>
    #include <Ice/Direct.h>
    #include <Ice/StreamF.h>
    #include </home/bloodymir/Download/Ice3.3slice2cpp/Ice3.3slice2cpp/A.h>
    #include <Ice/UndefSysMacros.h>
    

    So still wrong results.

    Regards,
    Frank
  • benoit
    benoit Rennes, France
    Hi Frank,

    I'm afraid it's a bug in the slice2cpp translator :( You should be able to workaround this issue by replacing -I. with -I./ in the slice2cpp command line options. I will post a source patch with a fix for this issue later today. Thanks for the report!

    Cheers,
    Benoit.
  • Hi!

    Using "-I./" as an option works like a charm. :) I hacked the build system to include this option and now I can already build the project using Ice 3.3.0

    Thank you!

    Frank
  • I ran into a similar issue with the slice2cpp compiler version 3.3.1. If I am compiling .ice files which are symlinks I need to -I the directory containing the .ice files in order to prevent absolute paths from being included in the header files.
  • Hi,

    We're having similar issues (Ice 3.5.1 on Debian Wheezy 64bit).
    Our project sources are symlinked, and we're using out-of-source build.

    For example, the "real" source tree, as pulled from git:
    /home/test/project/git/services.settings.slices/A.ice
    /home/test/project/git/services.settings.slices/B.ice
    

    The "symlinked" source tree (notice the difference in the paths, where a . becomes a /):
    /home/test/project/src/services/settings/slices/A.ice
    /home/test/project/src/services/settings/slices/B.ice
    

    Generated slice headers/sources should go into the build tree, which mimics the source tree:
    /home/test/project/build/gnu-make/gcc-elf/release/services/settings/slices/A.h
    /home/test/project/build/gnu-make/gcc-elf/release/services/settings/slices/A.cpp
      
    /home/test/project/build/gnu-make/gcc-elf/release/services/settings/slices/B.h
    /home/test/project/build/gnu-make/gcc-elf/release/services/settings/slices/B.cpp
    

    B.ice (includes A.ice)
    #include <services/settings/slices/A.ice>
    

    The path for this include directive is relative to the symlinked source tree, and also relative to the build tree.
    It's because it should be able to find A.ice (in the source tree) and, later on, the generated A.h (in the build tree)

    The problem is, when B.ice includes A.ice, it generates an absolute path for the header of A.
    So, the generated header "B.h" has:
    #include </home/test/project/src/services/settings/slices/A.h>
    

    This is the correct location of "A.ice" in the symlinked source tree, but it's not okay for the generated "A.h" header, which is located in the build tree.

    I'd expect a relative path, so what it should have been in "B.h" is:
    #include <services/settings/slices/A.h>
    

    Passing --include-dir works for the generated .cpp files (to include its corresponding header), but not for the generated headers which must include other slices.
    I've included all the possible -I dirs, but it didn't help. The slice2cpp command looks like this:
    slice2cpp --include-dir services/settings/slices -I. -I/home/test/project/build/gnu-make/gcc-elf/release -I/home/test/project/src --stream --output-dir /home/test/project/build/gnu-make/gcc-elf/release/services/settings/slices  /home/test/project/src/services/settings/slices/B.ice
    

    This has always worked for us before, but it broke down since we changed to a "symlinked" source tree.

    Could this be fixed, or do you know any workaround?
    Thank you very much!

    Wout
  • xdm
    xdm La Coruña, Spain
    Hi,

    We have looked into this and it seems to be a bug in how slice2cpp compiler deal with symbolic links, we will include a fix in the next release.
  • xdm wrote: »
    Hi,

    We have looked into this and it seems to be a bug in how slice2cpp compiler deal with symbolic links, we will include a fix in the next release.

    Thanks for the quick reply. I'm looking forward to the next release...
  • xdm
    xdm La Coruña, Spain
    Hi,

    I have posted a 3.5.1 patch for this issue here

    let us know if that fixed your problems

    Regards,
    Jose
  • Hi xdm,

    Great! I've tested it and it fixed the issue :-)
    Thanks for providing this patch so quickly!