[Rock-dev] about AUTOPROJ_PROJECT_BASE and code

Thomas Roehr thomas.roehr at dfki.de
Wed Jun 8 13:50:25 CEST 2011


On 08.06.2011 12:57, Sylvain Joyeux wrote:
> On 06/08/2011 12:26 PM, Thomas Roehr wrote:
>> On 08.06.2011 11:52, Janosch Machowinski wrote:
>>> Just to add one more opinion...
>>> I don't like it at all if code uses environment variables internally.
>>> This is
>>> because of the fact, that using an environmental variable hides some
>>> of the configuration of the Task, which is not visible to the user 
>>> unless
>>> he goes through the whole code.
>> a default (where it makes sense) does not hinder to configure the module
>> in other places, and proper log statements or error messages make it
>> unnecessary to get into the code in such cases.
>>
>>> And I believe hell will break loose if we start with this. Just 
>>> think about
>>> it if everybody introduces some ENV variables. The result would be
>>> that one needs to go through all the code to figure out how to use it
>>> (as documentation is always outdated).
>> In our project we make good use of the ConfigurationFinder using
>> ROCK_CONFIG_PATH and ConfigurationFinder package in utilmm
>>
>> Example:
>> std::string filename = utilmm::ConfigurationFinder::find("package-name",
>> "configfile");
>> to search for 'configfile' in
>> $ROCK_CONFIG_PATH/configuration/package-name/configfile/
> The additional configuration/ makes no sense. If it is 
> ROCK_CONFIG_PATH, then it should search in
Yes, that is what it does -faulty description here. Sorry for the 
confusion.
>
>   $ROCK_CONFIG_PATH/package-name/configfile/
>
>> To be able to specialize configurations (relies on the underscore as
>> separator):
>> std::string filename =
>> utilmm::ConfigurationFinder::findSystemConfig("package-name", crex_0);
>>
>> Searches
>> first in $ROCK_CONFIG_PATH/configuration/package-name/crex/0/
>> and falls back to $ROCK_CONFIG_PATH/configuration/package-name/crex/
>>
>> Similar for ruby.
> What happens if ROCK_CONFIG_PATH is not set ? The issue is that orogen 
> components SHALL be able to build even if ROCK_CONFIG_PATH is not set. 
> However, I personally feel that the config search
The build is completly independant of ROCK_CONFIG_PATH. It is a runtime 
issue, i.e. if it is not set it depends mainly on the component to 
handle this. However, the current implementation only prints a warning 
to stderr, when ROCK_CONFIG_PATH is not set, and searches in the local 
folder. Otherwise, it might be better to just throw an exception.


-- 
Thomas Röhr (M.Sc.)
Space Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454151
Fax:   +49 (0)421 178-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------



More information about the Rock-dev mailing list