All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Regarding 2a5e626aa6e08d894e74af053236947cced8ff87
       [not found]         ` <4A6A6747.8020007@garzik.org>
@ 2009-07-25  9:53           ` Fabian Deutsch
  2009-07-25 19:37             ` Jeff Garzik
  0 siblings, 1 reply; 2+ messages in thread
From: Fabian Deutsch @ 2009-07-25  9:53 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: hail-devel

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?

- fabian


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Regarding 2a5e626aa6e08d894e74af053236947cced8ff87
  2009-07-25  9:53           ` Regarding 2a5e626aa6e08d894e74af053236947cced8ff87 Fabian Deutsch
@ 2009-07-25 19:37             ` Jeff Garzik
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Garzik @ 2009-07-25 19:37 UTC (permalink / raw)
  To: Fabian Deutsch; +Cc: hail-devel

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-07-25 19:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1248353811.4605.9.camel@decade.local>
     [not found] ` <4A689245.5000204@garzik.org>
     [not found]   ` <1248370729.7812.1.camel@localhost.localdomain>
     [not found]     ` <4A68A7A3.4050606@garzik.org>
     [not found]       ` <1248443457.2444.13.camel@localhost.localdomain>
     [not found]         ` <4A6A6747.8020007@garzik.org>
2009-07-25  9:53           ` Regarding 2a5e626aa6e08d894e74af053236947cced8ff87 Fabian Deutsch
2009-07-25 19:37             ` Jeff Garzik

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.