Re: Regarding 2a5e626aa6e08d894e74af053236947cced8ff87

[Jeff Garzik <jeff@garzik.org>]

Fabian Deutsch wrote:
> Am Freitag, den 24.07.2009, 22:00 -0400 schrieb Jeff Garzik:
>> Fabian Deutsch wrote:
>>> Am Donnerstag, den 23.07.2009, 14:10 -0400 schrieb Jeff Garzik:
>>>> Fabian Deutsch wrote:
>>>>>>> Regarding the aboved mentioned commit, I'd suggest using 
>>>>>>>
>>>>>>> #define CLD_DEF_DATADIR        "/tmp/cld/lib"
>>>>>>>
>>>>>>> instead of 
>>>>>>>
>>>>>>> #define CLD_DEF_DATADIR        "/spare/tmp/cld/lib"
>>>>>>>
>>>>>>> as /tmp seems to be more present than /spare.
>>>>>> True, though ideally someone should go through Fedora and autotools, and 
>>>>>> figure out the proper location -- most likely somewhere in /var.  You 
>>>>>> never want permanent data in /tmp, either.  :)
>>>>> Yeah, reboots might have surprising effects :)
>>>>> Maybe something like the attached patch: Using autools vars to determin
>>>>> some paths ..
>>>> Your patch is heading in the right direction, but I have a few comments...
>>>>
>>>> * IIRC, AC_DEFINE() macro in configure.ac is the right place to define 
>>>> this sort of thing
>>> I've followed the recommended way mentioned here:
>>> http://www.gnu.org/software/autoconf/manual/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables
>>>
>>> AC_DEFINE shall not be used per se ...
>> Well, I disagree [with GNU], but it's a standard, so we'll go this way...
> 
> So, you two pence, why AC_DEFINE would be a betterw ay?

Not necessarily better, but more consistent.

*-config.h serves as the home for most configure-generated/set C 
pre-processor defines and macros.

It seems inconsistent that one or two special case CPP macros are found 
in the Makefile.am INCLUDES statements, rather than with the rest of the 
settings in *-config.h.

Or IOW, I like my C code [and C pre-processor code] in .c and .h files, 
not in Makefiles ;-)  Putting C defines or code in Makefiles violates 
the Principle of Least Surprise, in my opinion.

	Jeff