[Rock-dev] about AUTOPROJ_PROJECT_BASE and code

[Janosch Machowinski]

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


-- 
  Dipl. Inf. Janosch Machowinski
  SAR-&  Sicherheitsrobotik

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

  Phone: +49 (0)421 178 45-6614
  Fax:   +49 (0)421 178 45-4150
  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
  -----------------------------------------------------------------------