[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CONFIGURE_ENV, MAKE_ENV, SCRIPTS_ENV mess



I am considering cleaning up the mess that's become 
CONFIGURE_ENV, MAKE_ENV, SCRIPTS_ENV currently.

Namely:
- always use CONFIGURE_ENV for all configure styles, including imake,
or an external configure script.

- put everything that's used by configure into CONFIGURE_ENV.
(see the simple/gnu configure style for an example of what I'm talking about).

- be cleaner about gnu configure: only add all the ac_* env settings to
CONFIGURE_ENV if we are dealing with a gnu configure script.

- don't use SCRIPTS_ENV directly, keep it around as a handy repository for
the porter (if he has scripts that needs to know about PATCHDIR, WRKDIR
and whatnot).

Right now, what we have is almost impossible to document without making
explicit references to the existing implementation of bsd.port.mk, which is
a bad sign.  We also have somewhat redundant but not identical settings of
MAKE_ENV, CONFIGURE_ENV, SCRIPTS_ENV, whereas it would be better to have 
a much more regular set of env variables for each setting (this still causes
surprises: oh, I thought that CONFIGURE_ENV defined foo, whereas foo is
only in SCRIPTS_ENV).

Opinions ?
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'