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