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

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Benoit, All,

On Wednesday 25 May 2011 20:00:46 BenoÃt THÃBAUDEAU wrote:
> Yann, all,
> > I am not too fond of this patch for two reasons:
> > 1) libexpat should be provided by the host:
[--SNIP-]
> I think that keeping the current behavior is an issue. BuildRoot and
> many other build environments download and build locally host packages
> other packages depend on. In this way, there are no dependencies on
> the packages installed on the build system, both for build and runtime.

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...

> In this way, there are no dependencies on
> the packages installed on the build system, both for build and runtime.

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.

> In CT-NG, building GDB with or without libexpat will succeed, without
> the user even knowing that could make a difference.

*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.

> It also means that 
> a build of a toolchain performed with CT-NG is not reliably reproducible
> only from the .config file.

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

> > 2) code duplication to build libexpat
> >    - at least, provide a function that build libexpat, and takes as
> >      arguments: prefix, build and host
> >    - better yet, include it in the companion libraries
> >    infrastructure,
> >      even if there is no option and no version selection.
> 
> That could be done if you changed your mind on 1).

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...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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