[Rock-dev] about AUTOPROJ_PROJECT_BASE and code

[Sylvain Joyeux]

On 06/08/2011 11:38 AM, 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.
Because you feel that having to set multiple environment variables is a 
better thing ?

If I get a component from someone, the first thing I personally look at 
is "what are the properties". If there is a path, I set it. Because 
paths are project- (or even user-) dependent. If it is algorithms, then, 
yes, I expect them to be set properly.

In other words, my POV is: yes, one should not set more properties than 
required, but paths *are* properties that "are required".

The thing with setting a path "to a default value" is that it will VERY 
probably work only for YOUR project. So, you get it out of the box, but: 
it won't work for other projects *and*, in the end, orogen will bail out 
if the environment variable is not set. Moreover, other projects (like 
imoby) will probably have other policies (for instance, in imoby, we try 
to gather all configuration in the supervision's folder). And what about 
collisions: if everyone installs data in the same paths (or even 
"installs data", which is something that can also be discussed) it will 
become harder and harder to build and use things together (it is already 
hard).

Finally, and that's why I mentioned it, at least use the mechanism that 
already exists (ConfigurationManager)
-- 

Sylvain Joyeux
Space&  Security Robotics

!!! Achtung, neue Telefonnummer!!!

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

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-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
-----------------------------------------------------------------------