[Rock-dev] log file converter / updating frame.h SonarScan

Sylvain Joyeux sylvain.joyeux at dfki.de
Tue Sep 20 11:20:56 CEST 2011


On 09/20/2011 11:12 AM, Alexander Duda wrote:
>>> -->   add the package to the package set rock.toolchain
>>>
>>> -->   add a script rock-convert to base/scripts/bin which can be used to
>>> update base types (rock-convert logfile.0.log)
>> Why not put it in log_tools/bin (or, following your proposal,
>> post_proc.rb/bin) ???
> The reason is that this script is only for updating base types. For all
> the other types the user has to write his own script.
I don't see why we could not automatically load all the log_migration 
scripts

In general, I think it would start to be useful to have a ROCK_PREFIXES 
environment variable and look for things in subdirectories of that 
prefix (in this case, log/migration/). We could also have a vizkit/ 
subdirectory and use it to load vizkit extensions (they are currently 
loaded under lib/qt/designer/* which sucks -- I can say it, I added 
that)... and so on.
>>> -->   add conversions rules for base
>>> to /base/orogen/types/lib/base/immigrate
>> Mmmmm .... I would rather have a src/log_migration.rb file and install
>> it in share/rock/log/migration or something like that. In general, I
>> start to dislike the Ruby code that stays in CMake packages. It should
>> (in general) be installed with the rest of the package.
> Hmm that's bad for testing.
Why ? You have to install, which is something that you have to do anyway 
when you are manipulating C++ packages.

To refine my proposal:

   src/log_migration.rb would get installed as 
share/rock/log/migration/<package_name>.rb

Not installing these files is harmful as it will make debian package 
generation a lot harder. It is OK with pure Ruby packages as they have a 
standardized "behaviour", but cmake packages should really install 
everything they have.

Sylvain


More information about the Rock-dev mailing list