fastddsgen -d [19844]

[rookybird]

fastddsgen -d doesn't work as expected when the input idl using relative path.

For example, I have the following structure:

fastddsgenReport/
├── idl
│   └── helloworld.idl
└── modules
    └── helloworld
        └── ddsgen

If I am in the helloworld folder, and I run fastddsgen -d ddsgen ../../idl/helloworld.idl The output structure is:

fastddsgenReport/
├── idl
│   └── helloworld.idl
└── modules
    ├── helloworld
    │   └── ddsgen
    └── idl
        ├── helloworldCdrAux.hpp
        ├── helloworldCdrAux.ipp
        ├── helloworld.cxx
        ├── helloworld.h
        ├── helloworldPubSubTypes.cxx
        └── helloworldPubSubTypes.h

A new folder idl is created in parallel with folder helloworld, and the generated files which are supposed to be in ddsgen folder are happend to be in the newly created idl folder.

After doing more trials, I found that the relative path of the input acts on the destination path.

modules folder is two layers above the ddsgen folder. Then a new folder idl was created, which has the same name as the input folder's. The generated files are stored here.

If you clean, go to folder modules, and repeat the above test with command fastddsgen -d helloworld/ddsgen ../idl/helloworld.idl, you will have the following output structure:

fastddsgenReport/
├── idl
│   └── helloworld.idl
└── modules
    └── helloworld
        ├── ddsgen
        └── idl
            ├── helloworldCdrAux.hpp
            ├── helloworldCdrAux.ipp
            ├── helloworld.cxx
            ├── helloworld.h
            ├── helloworldPubSubTypes.cxx
            └── helloworldPubSubTypes.h

This bug only shows in fastddsgen v3.0.1. It is not happening in v2.4 or v2.3.

You can try to reproduce the issue with the attached zip.

fastddsgenReport.zip

[chunyisong]

I had the same issue as well! Without -d,source files should be created in the current directory running the command (not the directory of idl).

[richiware]

What you're describing is not an issue. It is a change on fastddsgen behaviour. We had to do this to fix several issues regarding generating code from several IDL files, when some of this file include another ones.

The key is to maintain the same directory structure where the IDL files are located, and the only way we found to do this is creating the generated code in the output directory (-d option or current directory) with the same directory structure the user passes with the IDL file.

For example using fastddsgen -d output my_idls/HelloWorld.idl will generate the code in ./output/my_idls.

As I said, this behaviour change fixes complex scenarios like:

.
├── inner
│   └── File.idl
├── other
│   └── Test2.idl
└── Test.idl

where Test.idl contains #include "inner/File.idl" and Test2.idl contains #include "../inner/File.idl".

Running fastddsgen Test.idl other/Test2.idl doesn't work with old versions. With this new behaviour, works.

@rookybird In your case I suggest to run fastddsgen -d ../modules/helloworld/ddsgen helloworld.idl from fastddsgenReport/idl directory.

And also I advice not to use ../ when specifying IDL file.