Hi Alexander, no, I am not responsible for this! It's true that I created the scripts in m4/, but I only copied what was previously in configure.in. Try:
svn up -r2 configure.in and you'll see that the code in question has been there since the beginning of SVN time (line 175). I cannot say why it was done that way. Probably because nobody needed a more general mechanism. Using pkgconfig seems like a good idea, but there should be a fallback method if pkgconfig is not installed or does not work. I think some of our autoconf tests already do something like this. -- Peter Alexander I. Gordeev wrote: > > Hi Peter! > > Sorry for disturbing you... > I've checked svn logs for m4 macros and it seems that you > are the only person to ask :) > > ------- Forwarded message ------- > From: "Alexander I. Gordeev" <[EMAIL PROTECTED]> > To: [email protected] > Cc: > Subject: [Nut-upsdev] m4 scripts ignore user-supplied CFLAGS and LDFLAGS= > > Date: Thu, 21 Feb 2008 03:33:26 +0300 > > Hi all, > > There is a discussion going on one russian forum about NUT > cross-compiling and packaging for some custom embedded firmware. > And one of the authors complained about NUT script for checking > ssl library ignoring supplied CFLAGS and LDFLAGS with the > desired include and library paths. > I checked several scripts in m4 folder and all of them do > something like this: > > CFLAGS_ORIG=3D"${CFLAGS}" > LDFLAGS_ORIG=3D"${LDFLAGS}" > > CFLAGS=3D"" > LDFLAGS=3D"..." > > at the beginning. Is it for purpose? Why not check first with > the user-supplied variables? > > I'm not very good in all this autotools magic so please > forgive me if this whole thing is dumb :) > > P.S. What is the "right" way of passing custom paths (for a > cross-compilation environment)? > > ------- Forwarded message ------- > > P.S. I think we should consider pkg-config, right? > > -- = > > Alexander > _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
