On Mon, Feb 05, 2001 at 02:42:44PM -0600, John Darrow wrote:
> Alistair Crooks <agc@pkgsrc.org> wrote:
> >On Sat, Feb 03, 2001 at 02:25:56PM -0500, Johnny C. Lam wrote:
> >> In light of the recent addition of ${FFLAGS} to ${CONFIGURE_ENV}, I
> >> think it's also desirable to add the following variables as well:
> >> 
> >> 	CPPFLAGS
> >> 	CXXFLAGS
> >> 
> >> as both are also used by GNU configure if they are defined in the
> >> environment.  We current define:
> >> 
> >> 	CFLAGS
> >> 	FFLAGS
> >> 	LDFLAGS
> >> 
> >> in ${CONFIGURE_ENV}.  Quite a lot of packages already do:
> >> 
> >> 	CONFIGURE_ENV+=	CPPFLAGS="${CPPFLAGS}"
> >> 
> >> and several C++ packages do the same with CXXFLAGS. I'm unsure as to
> >> why they aren't part of ${CONFIGURE_ENV} already.  Can anyone recall
> >> why?
> >
> >IIRC, it's to do with picking up the right header files, and linking
> >with the correct libs, if you already have an installed package for,
> >say (for example, off the top of my head, a known incorrect example),
> >ncurses, and are compiling a new version with a changed API.
> 
> If there are known packages with problems like this (or otherwise picking
> up dependencies they shouldn't be), should we perhaps have a per-package
> 'NO_CPPFLAGS_IN_CONFIGURE_ENV' which prevents the above from happening?
> Or maybe a 'NO_LOCALBASE_INCLUDE_IN_CPPFLAGS'?  i.e. something which allows
> most packages to have the default environment, with exceptions just for
> known issues...

Yes, a good idea, although I dislike the "NO_variable_name= YES" style of
writing - I much prefer "MK_CONFIGURE_ENV_WITH_CPPFLAGS= no" in package
Makefiles, with a MK_CONFIGURE_ENV_WITH_CPPFLAGS?= yes" in a central place.
That's just my little bete noir for the day, though, and the functionality
would be good to have.

I'll see what we can do.

Regards,
Alistair