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


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

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]