Re: is it best practice to use ${sysconfdir} rather than hard-coding "/etc"?

[Mark Hatle <mark.hatle@windriver.com>]

On 6/30/12 8:41 AM, Robert P. J. Day wrote:
> On Sat, 30 Jun 2012, Martin Jansa wrote:
>
>> On Sat, Jun 30, 2012 at 09:25:57AM -0400, Robert P. J. Day wrote:
>>>
>>>    i suspect i know the answer to this, but in the recipe file
>>> usbinit.bb, we have:
>>>
>>> do_install() {
>>>      install -d ${D}/etc
>>>      install -d ${D}/etc/init.d
>>>      install usb-gether ${D}/etc/init.d
>>> }
>>>
>>>    i'm guessing that would more properly be coded:
>>>
>>> do_install() {
>>>      install -d ${D}${sysconfdir}
>>>      install -d ${D}${sysconfdir}/init.d
>>>      install usb-gether ${D}${sysconfdir}/init.d
>>> }
>>>
>>>    the end result is functionally identical, of course, it's all just a
>>> matter of style.
>>
>> using sysconfdir is better as someone can define it to different value
>> then 'etc' and the later will still work (be consistent across image)
>
>    there are definitely a number of examples of hard-coded "/etc" in
> the recipes, but i'm not about to run around cleaning them -- i just
> wanted to make sure there was no compelling reason to do that
> hard-coding.  thanks.

There are instances where programs have hard coded paths, such as /etc/init.d. 
In those cases, it may be better to do the install and FILES_ work using the 
same hard coded path, since the item won't work if the variable version is renamed.

But for most things that use autoconf, the install locations are completely 
variable, so using the path variables is preferred.

My rule of thumb, if in doubt, use the path variables.  If you know that the 
path variables won't work for some reason -- either fix the problem, or use hard 
coded paths... IMHO this will help someone discover places that need to be 
modified if they ever change the value.

--Mark

> rday
>