This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


2011/5/25 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Benoit, Bryan, All,
>
> On Wednesday 25 May 2011 20:53:52 BenoÃt THÃBAUDEAU wrote:
>> > *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?
>
> The cross-gdb is pretty useless without it, so this has to be an error.
>
>> 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?
>
> If the user asked for a static build, then do a full static build.
> p;s/static/shared/
>
>> 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.
> [--SNIP--]
>> OK. The only issue I'd really like to see fixed here is the invisible
>> dependency on libexpat.
>
> OK, we have a few options here:
>
> 1) Do the check just when it is needed, in do_debug_gdb_build().
> Â This is the easiest, very lightweight, but inconvenient for the user
> Â as the build would have to be restarted.
>
> 2) Add a *_prepare function to the API, that gets call at the very beginning
> Â of the build, and does the necessary checks. Eg.:
> Â Â do_debug_gdb_prepare() {
> Â Â Â if [ ! "${libexpat_available}" ]; then
> Â Â Â Â ÂAaargh
> Â Â Â fi
> Â Â }
> ÂDo it everywhere.
> ÂAlso, have ./configure do the has_or_warn (as per Bryan's suggestion).
> ÂThis is pretty nice, and lightweight. Rather easy to implement, I think.
>
> 3) Provide a way to set defaults to options from ./configure
> Â - check shared & static libexpat at ./configure time
> Â - create a .in fragment at ./configure time, eg.:
> Â Â Â config CONFIG_LIBEXPAT_SHARED
> Â Â Â Â Â default y
> Â Â Â # CONFIG_LIBEXPAT_STATIC not set: not found
> Â - add the same option definitons in the top-level config.in,
> Â Â and include the .in framgent to set values
> Â - where applicable, depend on these options to show/hide some options,
> Â Â such as static gdb
> ÂThis is probably the most complete solution, but it is heavy-weight, maybe
> Âun-maintanable long-term, error-prone as it needs sync btw config.in and
> Â./configure, not easy to see where the defaults come from.
>
> I'd rather go for 2).

Yann,

I have other uses for 'has_or_warn' and setting
$some-external-lib_available as well.
For instance the problem that ANDY had with fedora packaging only
shared with -devel packages, and needing to install a seperate -static
package in the distribution would allow being able to toggle the
availability of building a static toolchain (i.e. if libncurses5.a is
not availble, don't allow static toolchains, but also warn during
./configure time.)

So I would opt for this solution.

I can provide the 'has_or_warn' code and an example with libncurses5.a
if you want, but you or BenoÃt should be able to implement
'has_or_warn' as well ;)
IOW... Eventually, I will need this functionality.

> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]