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