[Rock-dev] about AUTOPROJ_PROJECT_BASE and code

[Thomas Roehr]

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/

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.

> Greetings
>       Janosch
>
> On 08.06.2011 11:38, Alexander Duda wrote:
>> On Wed, 2011-06-08 at 10:32 +0200, Sylvain Joyeux wrote:
>>> AUTOPROJ_PROJECT_BASE is an environment variable that has been
>>> (sneakily) added recently to some builds.
>>>
>>> It should NOT be used in code. EVER. It makes the packages dependent on
>>> having the whole build being done by autoproj, which is something we
>>> must avoid.
>>>
>>> If you *really* need it, in C++ code, there is a "standard"
>>> configuration search tool in utilmm: ConfigurationFinder
>>>
>>>
>>> http://rock-robotics.org/api/utilmm/classutilmm_1_1ConfigurationFinder.html
>>>
>>> which depends on a ROCK_CONFIG_PATH variable.
>> I don't agree here. Using an environment variable for a default value of
>> a property does not make the component autoproj depending even if the
>> variable is set by autoproj. The worst think which can happen is that
>> the default path is set to a wrong location (which would be bad for
>> output paths).
>>
>> But I agree the variable AUTOPROJ_PROJECT_BASE is misused. Therefore I
>> think it would be good if we introduce an environment variable which
>> points to the default configuration folder to relief the user of setting
>> it for every component which has configuration files.
>>
>>> In any case, this should not be used in orogen code. If you want a
>>> property to point to a location, just let the people write it ! That's
>>> the whole point of properties !
>> I see the properties more as possibility to modify the default behavior.
>> And for me it is a bad design if someone wants to use an other component
>> and has to configure more than absolute necessary to get it running.
>>
>> Alex
>>
>


-- 
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
-----------------------------------------------------------------------