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

[Bryan Hundven <bryanhundven at gmail dot com>]

2011/5/25 Yann E. MORIN <yann.morin.1998@anciens.enib.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...

I agree with Yann. If we want this, maybe just add another
'has_or_abort', or I suggest having a 'has_or_warn' and setting a
CONFIG_ variable saying that you have libexpat or not, so gdb does the
right thing.
Maintaining companion libraries is a pita.

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

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