[PATCH 1 of 2] cross-gdb: add XML support

[Benoît THÉBAUDEAU]

Yann, all,

> Granted. They do that stuff. The question is: how far do we want to
> go?
> I'm mostly alone in maintaining and evolving crostool-NG, and I see
> the
> burden falling onto me to support a new companion library yet again;
> and
> then a new companion tool, and then a new [whatever], that could also
> be
> installed using the distro's packages.
>
> Plus, the maintenance work done by the distros far outweights what I
> could possibly do to fix/update/... this companion stuff...

I agree.

> You already have tons of dependencies: a native toolchain,
> libncurses,
> bash, proper sed and grep, make, awk, bison, flex, and so on...
> One more won't kill us.
>
> The issue is that there is currently no way to deactivate features in
> the
> menuconfig, based on stuff found by ./configure; so we have to check
> it
> at (ct-ng's) runtime.

Indeed.

> *This* is the real issue: the user not knowing something went bad,
> and
> discovering only at runtime. The solution to this issue is not to
> build
> libexpat, but to fail early, before even gdb gets compiled.
>
> I believe the real fix would be to fix that.

I agree.

How could we do that?
 - We could create a configure-like function in the scripts that would
test for the presence of libexpat on the build system, and fail if not
found.
 - We could add '--with-expat=yes' to the configure options of cross-gdb.
In that way, the configure of cross-gdb would fail if libexpat is not
present, but that failure could occur very late in the toolchain build.

Should we force an error or leave a warning? If --with-expat is not given
or set to auto, there is already a warning issued by the configure of
cross-gdb if libexpat is not found, but it is deeply hidden in the build
log.

Should libexpat be linked statically or dynamically? A dynamic link would
create a runtime dependency of cross-gdb on libexpat, which may be a
problem when moving a built toolchain from one machine to another.

> Right. I agree that having crosstool-NG's [version,.config] should be
> enough
> to reproduce the toolchain.

OK.

> I said I was "not too fond of this patch". I did not say I will not
> take it. If you can give good arguments in favor if the change, then
> I can change my mind. I did not say 'no'. ;-)
>
> So far, you did not manage to convince me. The only reason that you
> could
> really push for the inclusion is related to canadian-cross. I do
> believe
> that the upper layer build-system should be responsoble for
> installing
> libexpat, but this is not written in stone. I am really pondering to
> include
> it just for this reason. But yet, I am not really happy to do so
> either...

OK. The only issue I'd really like to see fixed here is the invisible
dependency on libexpat.

Regards,
Benoît

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