When configuring a package outside the source directory (which is the recommended method, isn't it?), it is impossible to use econf, because it looks for "./configure". Could you make econf support an environment variable maybe? I was looking at the spec file of ncurses from the Mandrake distribution and I saw this kind of invocation: mkdir -p ncurses-utf8 pushd ncurses-utf8 CONFIGURE_TOP=.. %configure2_5x \ --includedir=%{_includedir}/ncursesw \ --with-normal --with-shared --without-debug --without-profile \ --with-gpm --enable-termcap --enable-getcap \ --enable-const --enable-hard-tabs --enable-hash-map \ --enable-no-padding --enable-sigwinch --without-ada \ --enable-widec The idea is nice and the extra functionality wouldn't hurt anyone.
> When configuring a package outside the source directory > (which is the recommended method, isn't it?) Recommended by whom ? I've never seen anyone doing that before. I certainly don't know everything, but a reference would be nice.
Forget the comment about it being the recommended method, since it is not relevant. I just thought it would be useful for packages that are double-compiled with different options, because of minor incompatiblities of certain options. One package that comes to mind is proftpd. In my overlay, I make it compile binaries with and without ipv6 support, because an ipv6 enabled version throws too many warnings when an ipv4 connection is incoming. This is only my overlay, but still... I was also working on ncurses -- I wanted to make it install a --enable-wchar and --disable-wchar versions (accomplished already; idea stolen from the rpm I mentioned in the original post). I guess there may be other packages that would benefit from the extra functionality. The only real-life example of an ebuild I can think of right away is glibc -- it requires that it is built in a directory different from the location of the sources. Well, at least it strongly discourages against building in the directory where the sources are. As to why it is a good idea: the building process becomes cleaner. If the object files are separated from the sources, ebuilds could afford to clean their build directory in the very beginning of src_compile(). This way, running "ebuild foo.ebuild compile" a few times in a row, would be a cleaner process. However, I doubt that many ebuilds would use it. Most important, however, is that making econf aware of a variable would not disrupt anything, and even if it is not going to be used very often, I can see that it could be useful.
ECONF_SOURCE == Path to configure, not including the 'configure' part.
Bug has been fixed and released in stable portages on or before 2.0.51-r2
