[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