panic after printing "Reading lib spec", "No such file or directory"

[alexchandel]

Running with cargo run, I get this panic message, even in release profile. Mysteriously unhelpful panics in release builds are one of the reasons I avoid panic! and unwrap at all costs. What file or directory is it looking for?

[emoon]

Did you run according to the docs here? https://github.com/rust-qt/cpp_to_rust#running-from-command-line

[emoon]

You can also try to use one of the scripts here https://github.com/rust-qt/cpp_to_rust/tree/master/scripts to making it a bit easier to run.

[alexchandel]

I eventually realized it was looking for a Cargo.toml in the C++ source's folder and stuck a dummy one in. The documentation didn't mention it. try! or some error parsing might help given how many times unwrap() is called in run().

[alexchandel]

Does this not support using just a folder of C++ code? The C++ headers I'm trying to generate an interface for aren't installed globally. They (and the c/cxx files) are all the folder I'm passing cpp_to_rust.

[Riateche]

Format of input data is not yet documented, unfortunately. It was undergoing changes recently. You can use this repository as example of input data in currently supported format. I'm going to write documentation for this soon.

I'm using unwrap for keeping balance between total lack of error handling and handling any possible errors. There is just too much that can theoretically go wrong in the process, so I'm unable to handle everything. So, for now, the plan is to improve error messages for the most common errors. I'll fix the "no such file" error.

Panics are not that hard to track down. When running a debug build, the stack trace will contain names of functions and line numbers where the panic has happened.

Does this not support using just a folder of C++ code? The C++ headers I'm trying to generate an interface for aren't installed globally. They (and the c/cxx files) are all the folder I'm passing cpp_to_rust.

No, that won't work out of box. The generator currently uses qmake (a Qt-specific tool) to find out include path and library path of the C++ library. It will not do it if it's not a Qt library. It will probably work if the library is installed system-wide (but I didn't check it yet), but not otherwise. The information about these paths should come from the lib spec, but it's not implemented yet. So the generator will fail to compile the C wrapper.

Can you share the library you're trying to wrap? I want to try it and fix the issues.

[alexchandel]

Now that I see what I was missing, perhaps a better title for this issue would be "Better error messages for early fatal errors."

Sure, it's just an old CORBA server + client that I'm trying to use with omniorb 4.2.1. Just use the C++ header generated from an example IDL file like this:

module Example {
    enum FooT { Foo1, Foo2 };
    struct FooS {
        FooT discriminant;
    };
    typedef sequence<FooS> FooL;
    exception FooE {
        long data
        string message;
    };
    interface FooBar {
        FooL fooBar(in string baz) raises(FooE);
    };
}

The errors come from the omniOrb headers alone as well.

[Riateche]

I've started to fix errors that are encountered in omniorb. I'll let you know how it goes.