Re: [PATCH v2 3/4] INSTALL/configure: Update install doc and configure comment

[Leif Lindholm <leif@nuviainc.com>]

On Tue, Apr 21, 2020 at 16:55:25 +0200, Daniel Kiper wrote:
> > > > >  You need to use following options to specify tools and platforms. For minimum
> > > > >  version look at prerequisites. All tools not mentioned in this section under
> > > > > @@ -182,28 +182,31 @@ corresponding platform are not needed for the platform in question.
> > > > >
> > > > >    - For host
> > > > >      1. --host= to autoconf name of host.
> > > > > -    2. CC= for gcc able to compile for host
> > > > > -    3. HOST_CFLAGS= for C options for host.
> > > > > -    4. HOST_CPPFLAGS= for C preprocessor options for host.
> > > > > -    5. HOST_LDFLAGS= for linker options for host.
> > > > > -    6. PKG_CONFIG= for pkg-config for host (optional).
> > > > > -    7. Libdevmapper if any must be in standard linker folders (-ldevmapper) (optional).
> > > > > -    8. Libfuse if any must be in standard linker folders (-lfuse) (optional).
> > > > > -    9. Libzfs if any must be in standard linker folders (-lzfs) (optional).
> > > > > -    10. Liblzma if any must be in standard linker folders (-llzma) (optional).
> > > > > +    2. CC= for gcc able to compile for host and target.
> > > >
> > > > But this is incorrect? Apart from where HOST == TARGET? And goes
> > > > against the example updated above.
> > > > Am I missing something?
> > >
> > > It is correct, CC applies for host and target...
> >
> > So why do we have TARGET_CC and HOST_CC?
> >
> > My understanding is:
> > - CC sets the default compilet binary, used for BUILD, HOST and TARGET
> >   unless overridden for each of these.
> 
> Nope, just HOST_CC and TARGET_CC. You can override CC using TARGET_CC and
> HOST_CC respectively. Order in configure command line does not matter.

I wasn't suggesting command line order mattered.

> > - The value of BUILD_CC is used as default for HOST_CC unless
> >   HOST_CC is explicitly specified.
> 
> Nope, it is not.
> 
> > - The value of HOST_CC is used as the default for TARGET_CC, where *it*
> >   is not explicitly specified.
> 
> Nope, it is not.
> 
> > Either my understanding here is incorrect, or these changes make the
> > text more rather than less misleading.
> 
> Sorry but I am not sure what is unclear after my changes.

OK, I concede configure.ac completely ignores the value of CC for
setting BUILD_CC. It tests for a hard-wired set of commands (which
seems weird to me, but some googling suggests that is indeed default
behaviour - I guess overriding the BUILD_ toolchain is the *least*
common use case).

But let me rewind:

configure scripts support separate concepts of BUILD, HOST and TARGET
to permit things like cross-compiling a tool on an AMD64 box (BUILD) to
run on an armhf box (HOST) to generate images to run on SPARC
(TARGET).

CC is traditionally used to override just using the first "gcc"
command to find a (apparently HOST_) toolchain.

But if I set both HOST_ and TARGET_ options for my build, I expect the
target to be built using the TARGET_ toolchain. If I specify CC and
TARGET_CC, I expect the target to be built with TARGET_CC. Which is
thankfully also what happens in reality.

However, the proposed change now says that HOST_CC sets the host and
target compiler and that TARGET_CC sets the target compiler. This is
not even self-consistent.

I get what the change is trying to say, but I feel it is only adding
confusion. I think the same thing could be adequately conveyed by
adding something along the lines of:
"If no target options are given, these will default to be the same as
the host options."
immediately below the - "For target" line

I don't think adding description of CC/CFLAGS to target section
improves clarity. If CFLAGS should be separately speficied, I think
that makes more sense next to HOST_CFLAGS.

And I think if we're changing this, we should add an entry for HOST_CC
- or add that to the existing CC option.

Regards,

Leif