Re: Configure problem

[Daniel Jacobowitz <drow at false dot org>]

On Tue, May 18, 2004 at 06:39:34PM -0700, Jim Wilson wrote:
> On Tue, 2004-05-18 at 14:13, Daniel Jacobowitz wrote:
> > How?  When I do this, config.status is rerun, but configure isn't. 
> 
> Good question.  At the time, I was so convinced that I knew the answer
> that I didn't double check my facts.  I did manage to generate the same
> error that Zdenek saw, but the commands I listed could not have done
> this.
> 
> I poked at this a bit, and came up with a way that I can reproduce.
>   make all-target-libobjc
>   touch ../gcc/libobjc/configure
>   make all-target-libobjc
>   rm i686-pc-linux-gnu/libobjc/Makefile
>   make all-target-libobjc
> The second make creates a config.cache file that has target_alias set. 
> The third make does a configure with target_alias unset, but sees the
> config.cache file with it set, and complains about the discrepancy.
> 
> Someone is unlikely to do this by accident, but one way this can happen
> is
>   make
>   cvs update
>   make
>   ../gcc/configure ...
>   make
> Reconfiguring will delete the subdir Makefiles, to force them to be
> reconfigured.

OK, that makes sense.  Thanks.

> By the way, I saw a new related problem today.  The tree-ssa patch added
> GMPINC and GMPLIB to the subconfigure variable list, but not the submake
> variable list.  So now it is possible to get the same problem in the gcc
> directory with GMPINC and/or GMPLIB.  They need to be added to
> BASE_FLAGS_TO_PASS or something equivalent to fix this.

Oopsie.  Well, I'll add this to the list of things to fix when we
settle on a solution.  It's not hard to find the complete list with
grep; look for ^ac_env_ in configure scripts.

> > 	* Makefile.tpl (configure-build-[+module+]): Export aliases
> > 	for build targets.
> > 	(configure-target-[+module+]): Likewise for target modules.
> > 	(configure-[+module+], configure-gcc, configure-stage1-gcc)
> > 	(configure-stage2-gcc, configure-stage3-gcc): Likewise for host
> > 	modules.
> > 	* Makefile.in: Regenerated.
> 
> My patch was approved by DJ by the way.  I didn't self approve it, and
> the first version of my patch had a stupid mistake (patched a generated
> file).  I'll defer to the config maintainers if they want to comment.

Which patch?  I thought you were referring to the LDFLAGS patch, which
was checked in, so I didn't go looking for another.

> I think exporting all of build/alias/target for all configures is
> redundant.  configure translates --build/--host/--target options into
> build_alias/host_alias/target_alias variables.  So there is no need to
> export a variable that will be overridden by a configure option.
> 
> Also, there is a conflict here only because the sub-make export list
> does not match the sub-configure export list.  Only target_alias is in
> the sub-make export list, so we really only need to put target_alias in
> the sub-configure export list.

They all get exported, though.  See libobjc/Makefile, which defines
build_alias and does not use .NOEXPORT.

> There is a problem for target subdirectories, because the toplevel
> configure only passes the --build and --host options, and thus only
> build_alias and host_alias get set in the resulting config.cache. 
> However, the make passes target_alias to sub-makes, causing all three of
> build/host/target_alias to be set when running config.status --recheck
> from a submake.  So all we need to do is add target_alias to the
> configure export list to solve this problem.  We only need this for
> target and build sub-configure rules.
> 
> An alternative solution would be to add --target options to
> TARGET_CONFIGARGS and BUILD_CONFIGARGS.

That gets us back into the "what do all these arguments mean" dance
with autoconf.  Current best practice appears to be to not use the
--target when not absolutely necessary.

-- 
Daniel Jacobowitz