Re: [PATCH] debug/cross-gdb: check host dependencies

[BenoÃt THÃBAUDEAU <benoit dot thebaudeau at advansee dot com>]

Yann, all,

> Your checking for both the header and the libs (twice, once for
> expat, and
> once for Python) really seems to imply we need a way to check both at
> the
> same time.
[--SNIP--]
> Why do we need to have two options: headers and libs? Can't we live
> with
> a single option that is the 'aggregate' of the two?
>
> Indeed, the ./configure infrastructure currently does not allow
> checking
> both a header *and* a lib atomically; we currently need to call
> has_or_*
> twice, once for the lib, once for the header. Maybe it would make
> sense
> to be able to check both in a single run?
[--SNIP--]
> Briefly looking at the code, it seems rather easy. We migh just need
> to
> change:
>   case "${prog}:${inc}:${lib}" in
>     ...
>   esac
>
> with a succession of independent if-then-fi:
>   if [ -n "${prog}" ]; then
>     ...
>   fi
>   if [ -n "${inc}" ]; then
>     ...
>   fi
>   if [ -n "${inc}" ]; then
>     ...
>   fi
>
> This way, we can check at the same time a prog, an inc and a lib. Not
> sure
> it makes sense to check for a prog, except maybe if we want to check
> a
> version at the same time, such as (purely fictitious):
>   has_or_abort prog="expat-config" ver="1.2.3" \
>                inc="expat.h"                   \
>                lib="libexpat.so"               \
>                err="'libexpat 1.2.3' is required to foobar the buz"
>
> Dunno...

That would indeed be a good idea, but it's not that simple because of ${status}
(it can be duplicated as a solution) and especially of ${var}. What does ${var}
apply to when several of prog/inc/lib are passed at once? Should we simply
forbid this usage?

> I would like to avoid as much as possible that early options in the
> menu
> depends on later options. I mean, I want to avoid the user having to
> go
> back and forth in the menuconfig to see if new options appeared or
> disapeared.
>
> CT_STATIC_TOOLCHAIN is early is the menu, while CT_GDB_CROSS is much
> later. Which means that, given this initial state (static expat
> missing):
>   CT_GDB_CROSS=y
>
> then firing menuconfig, going to disable CT_GDB_CROSS. This means
> that the
> CT_STATIC_TOOLCHIAN option suddenly appears, and the user would have
> to go
> back into an earlier menu to see that a new option is available.
>
> I would suggest that we instead have CT_GDB_CROSS depends on
> CT_STATIC_TOOLCHAIN, a bit like:
>
>   config GDB_CROSS
>       bool
>       depends on ! STATIC_TOOLCHAIN || has_static_expat
>       depends on has_expat_lib && has_expat_hdr
>
> This means that, CT_STATIC_TOOLCHAIN will not depend on CT_GDB_CROSS,
> while
> CT_GDB_CROSS will indeed not be selectable is static toolchain is
> required,
> but static expat is missing.
>
> Yes, this is the reverse as what is done for the static libstdc++.
> But that's
> not really the same context. libstdc++ *is* absolutely required to
> build a
> toolchain; static libstdc++ *is* absolutely requried to build a
> static
> toolchain.
>
> OTOH, static libexpat is *not* absolutely required. It just means
> that a sub,
> non-mandatory component is not buildable.

That makes sense. I'll do that. It's only a matter of priorities between
config options.

> > +            --with-expat=yes                            \
>
> Don't we have to disable something if Python is missing, or is it
> automagic?

Both expat and python are autodetected by gdb's configure by default.

'--with-expat=yes' could be removed since the expat issue is already handled
by the config, but I prefer to keep it to insist on the fact that we want to
make expat compulsory as this option makes gdb's configure fail if expat is
not detected.

Best regards,
BenoÃt

--
For unsubscribe information see http://sourceware.org/lists.html#faq