all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* gdb-ui.el assumes images support
@ 2004-11-06 17:03 Eli Zaretskii
  2004-11-07  0:23 ` Nick Roberts
  2004-11-07 18:04 ` Richard Stallman
  0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2004-11-06 17:03 UTC (permalink / raw)


This line from gdb-ui.el:

  (define-fringe-bitmap 'breakpoint
         "\x3c\x7e\xff\xff\xff\xff\x7e\x3c")

causes the Emacs build to fail if it is configured --without-x, since
fringe.c is not compiled then.  (gdb-ui.el affects the build because
tooltip.el says "(require 'gdb-ui)".)

I fixed it temporarily by conditioning define-fringe-bitmap by images
being supported, but that's a kludge, as it breaks the possibility to
prepare an Emacs tarball on a system where Emacs is built without X,
which is typical of making a tarball on fencepost.  So a better change
is required (why does tooltip.el need to require gdb-ui, anyway?).

^ permalink raw reply	[flat|nested] 34+ messages in thread

* gdb-ui.el assumes images support
  2004-11-06 17:03 gdb-ui.el assumes images support Eli Zaretskii
@ 2004-11-07  0:23 ` Nick Roberts
  2004-11-07  4:48   ` Eli Zaretskii
  2004-11-07 18:04 ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Nick Roberts @ 2004-11-07  0:23 UTC (permalink / raw)
  Cc: emacs-devel


 > ...(why does tooltip.el need to require gdb-ui, anyway?).

tooltip.el doesn't require gdb-ui. 

emacs -q

`C-h v' features

features's value is 
(help-fns help-mode view button tooltip image tool-bar disp-table mwheel x-dnd fontset ediff-hook vc-hooks lisp-float-type lisp-mode register page menu-bar timer select scroll-bar mldrag mouse facemenu font-core frame ucs-tables georgian utf-8-lang misc-lang vietnamese tibetan thai lao korean japanese hebrew greek romanian slovak czech european ethiopic kannada tamil malayalam devanagari indian cyrillic chinese case-table help simple faces cus-face text-properties overlay md5 base64 format mule env custom widget backquote make-network-process x-toolkit)

tooltip is present, while gdb-ui isn't.

You are probably referring to the fact that tooltip does require gdb-ui for
compilation (eval-when-compile). tooltip.el contains lisp functions from
gdb-ui.el like gdb-enqueue-input and as someone had already `required' gud for
compilation I followed suit and added gdb-ui. Is this what is causing the
problem?

I'm not a lisp expert but there is only one macro in tooltip.el
(tooltip-region-active-p) which doesn't use functions from gud or gdb-ui, so
perhaps these requires aren't necessary? Anyone?

Nick

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07  0:23 ` Nick Roberts
@ 2004-11-07  4:48   ` Eli Zaretskii
  2004-11-07 10:35     ` Andreas Schwab
  2004-11-08 16:59     ` Richard Stallman
  0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2004-11-07  4:48 UTC (permalink / raw)
  Cc: emacs-devel

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 7 Nov 2004 13:23:14 +1300
> Cc: emacs-devel@gnu.org
> 
> You are probably referring to the fact that tooltip does require gdb-ui for
> compilation (eval-when-compile).

Yes.

> tooltip.el contains lisp functions from
> gdb-ui.el like gdb-enqueue-input and as someone had already `required' gud for
> compilation I followed suit and added gdb-ui. Is this what is causing the
> problem?

Yes.

> I'm not a lisp expert but there is only one macro in tooltip.el
> (tooltip-region-active-p) which doesn't use functions from gud or gdb-ui, so
> perhaps these requires aren't necessary? Anyone?

Perhaps it is not necessary, but the real problem is that gdb-ui.el
cannot be compiled on a system where define-fringe-bitmap is not
defined.  That is a Bad Thing, IMHO, and that is the problem we should
fix.

Can the use of define-fringe-bitmap moved to the run-time rather than
compile time?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07  4:48   ` Eli Zaretskii
@ 2004-11-07 10:35     ` Andreas Schwab
  2004-11-07 22:12       ` Eli Zaretskii
  2004-11-08 16:59     ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2004-11-07 10:35 UTC (permalink / raw)
  Cc: Nick Roberts, emacs-devel

"Eli Zaretskii" <eliz@gnu.org> writes:

> Perhaps it is not necessary, but the real problem is that gdb-ui.el
> cannot be compiled on a system where define-fringe-bitmap is not
> defined.  That is a Bad Thing, IMHO, and that is the problem we should
> fix.

Actually gdb-ui.el can be compiled (which won't eval such toplevel forms),
but not loaded on such a system.  Maybe we should add a dummy definition
for define-fringe-bitmap when configured without X?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-06 17:03 gdb-ui.el assumes images support Eli Zaretskii
  2004-11-07  0:23 ` Nick Roberts
@ 2004-11-07 18:04 ` Richard Stallman
  2004-11-08 12:47   ` Kim F. Storm
  1 sibling, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2004-11-07 18:04 UTC (permalink / raw)
  Cc: emacs-devel

    This line from gdb-ui.el:

      (define-fringe-bitmap 'breakpoint
	     "\x3c\x7e\xff\xff\xff\xff\x7e\x3c")

    causes the Emacs build to fail if it is configured --without-x, since
    fringe.c is not compiled then.

Would moving the definition of this function to another file
solve the problem?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07 10:35     ` Andreas Schwab
@ 2004-11-07 22:12       ` Eli Zaretskii
  2004-11-08 10:15         ` Andreas Schwab
  2004-11-08 16:58         ` Richard Stallman
  0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2004-11-07 22:12 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

> Cc: Nick Roberts <nickrob@snap.net.nz>, emacs-devel@gnu.org
> From: Andreas Schwab <schwab@suse.de>
> Date: Sun, 07 Nov 2004 11:35:39 +0100
> 
> Actually gdb-ui.el can be compiled (which won't eval such toplevel forms),
> but not loaded on such a system.

Yes, but the problem is, tooltip.el requires gdb-ui.el at compile
time, so tooltip.el cannot be compiled if gdb-ui.el uses
define-fringe-bitmap unconditionally.

> Maybe we should add a dummy definition for define-fringe-bitmap when
> configured without X?

If we did that, and gdb-ui.el is compiled with Emacs built without X,
would the resulting gdb-ui.elc be good for use on X?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07 22:12       ` Eli Zaretskii
@ 2004-11-08 10:15         ` Andreas Schwab
  2004-11-08 12:11           ` Eli Zaretskii
  2004-11-08 16:58         ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2004-11-08 10:15 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Maybe we should add a dummy definition for define-fringe-bitmap when
>> configured without X?
>
> If we did that, and gdb-ui.el is compiled with Emacs built without X,
> would the resulting gdb-ui.elc be good for use on X?

Sure, since it's not a macro.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 10:15         ` Andreas Schwab
@ 2004-11-08 12:11           ` Eli Zaretskii
  0 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2004-11-08 12:11 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

> From: Andreas Schwab <schwab@suse.de>
> Date: Mon, 08 Nov 2004 11:15:08 +0100
> Cc: nickrob@snap.net.nz, emacs-devel@gnu.org
> 
> > If we did that, and gdb-ui.el is compiled with Emacs built without X,
> > would the resulting gdb-ui.elc be good for use on X?
> 
> Sure, since it's not a macro.

Then this is an okay solution, I think.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07 18:04 ` Richard Stallman
@ 2004-11-08 12:47   ` Kim F. Storm
  2004-11-08 14:55     ` Stefan
  0 siblings, 1 reply; 34+ messages in thread
From: Kim F. Storm @ 2004-11-08 12:47 UTC (permalink / raw)
  Cc: Eli Zaretskii, emacs-devel

Richard Stallman <rms@gnu.org> writes:

>     This line from gdb-ui.el:
>
>       (define-fringe-bitmap 'breakpoint
> 	     "\x3c\x7e\xff\xff\xff\xff\x7e\x3c")
>
>     causes the Emacs build to fail if it is configured --without-x, since
>     fringe.c is not compiled then.
>
> Would moving the definition of this function to another file
> solve the problem?

It is defined in fringe.c when HAVE_WINDOW_SYSTEM, so it's not
easy to move.

Perhaps we could add this to subr.el:

(unless widow-system
  (defun define-fringe-bitmap (&optional rest)
    "Dummy function for text-only terminals."))

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 12:47   ` Kim F. Storm
@ 2004-11-08 14:55     ` Stefan
  0 siblings, 0 replies; 34+ messages in thread
From: Stefan @ 2004-11-08 14:55 UTC (permalink / raw)
  Cc: Eli Zaretskii, rms, emacs-devel

> (unless widow-system
>   (defun define-fringe-bitmap (&optional rest)
>     "Dummy function for text-only terminals."))

I don't want to enter into arguments about the value of marriage, but I'd
rather replace widow-system by (fboundp 'define-fringe-bitmap) in the above.


        Stefan

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07 22:12       ` Eli Zaretskii
  2004-11-08 10:15         ` Andreas Schwab
@ 2004-11-08 16:58         ` Richard Stallman
  2004-11-08 20:38           ` Nick Roberts
  1 sibling, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2004-11-08 16:58 UTC (permalink / raw)
  Cc: schwab, nickrob, emacs-devel

    Yes, but the problem is, tooltip.el requires gdb-ui.el at compile
    time,

Can't we get rid of that dependency?
What is the reason for it anyway?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-07  4:48   ` Eli Zaretskii
  2004-11-07 10:35     ` Andreas Schwab
@ 2004-11-08 16:59     ` Richard Stallman
  2004-11-09  4:28       ` Eli Zaretskii
  1 sibling, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2004-11-08 16:59 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

Maybe we should include fringe.c unconditionally, so that defining and
looking up fringe bitmaps will always work, whether or not Emacs
can actually display them.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 16:58         ` Richard Stallman
@ 2004-11-08 20:38           ` Nick Roberts
  2004-11-08 21:23             ` Kim F. Storm
  2004-11-09 21:29             ` Richard Stallman
  0 siblings, 2 replies; 34+ messages in thread
From: Nick Roberts @ 2004-11-08 20:38 UTC (permalink / raw)
  Cc: schwab, Eli Zaretskii, emacs-devel


 >     Yes, but the problem is, tooltip.el requires gdb-ui.el at compile
 >     time,
 > 
 > Can't we get rid of that dependency?
 > What is the reason for it anyway?

Yes. I don't think its needed, but gdb-ui is designed to work on text-only
terminals and presumably it won't currently when configured without X?

Anyway, tooltip.el has:

(eval-when-compile
  (require 'cl)
  (require 'comint)
  (require 'gud)
  (require 'gdb-ui))

I added the last require after Gerd Moellmann included the others. My
understanding now is that a file only requires another, at compilation,
if it uses a macro defined in that other file.

If this is the case, tooltip does not need the last three requires,
and requiring cl just seems to redefine push for compilation, so
perhaps thats not needed either.

It's sometimes hard to see why files are required at compilation, so it may
be good practice to add a comment as in vc.el:

(eval-when-compile
  (require 'cl)
  (require 'compile)
  (require 'dired)      ; for dired-map-over-marks macro
  (require 'dired-aux))	; for dired-kill-{line,tree}

I see that dired is required, but dired-kill-line, dired-kill-tree are not
macros so is dired-aux required? I think not, but if the answer is yes that
would explain the need for the requires in tooltip.

Nick

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 20:38           ` Nick Roberts
@ 2004-11-08 21:23             ` Kim F. Storm
  2004-11-08 22:05               ` Kevin Rodgers
  2004-11-09 21:29               ` Richard Stallman
  2004-11-09 21:29             ` Richard Stallman
  1 sibling, 2 replies; 34+ messages in thread
From: Kim F. Storm @ 2004-11-08 21:23 UTC (permalink / raw)
  Cc: schwab, Eli Zaretskii, rms, emacs-devel

Nick Roberts <nickrob@snap.net.nz> writes:

> I added the last require after Gerd Moellmann included the others. My
> understanding now is that a file only requires another, at compilation,
> if it uses a macro defined in that other file.

It may also require another file simply to avoid warnings for using
undefined functions that are defined in that file.  

How else would you avoid such warnings?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 21:23             ` Kim F. Storm
@ 2004-11-08 22:05               ` Kevin Rodgers
  2004-11-08 23:54                 ` Nick Roberts
  2004-11-09 14:11                 ` Kim F. Storm
  2004-11-09 21:29               ` Richard Stallman
  1 sibling, 2 replies; 34+ messages in thread
From: Kevin Rodgers @ 2004-11-08 22:05 UTC (permalink / raw)


Kim F. Storm wrote:
 > Nick Roberts <nickrob@snap.net.nz> writes:
 >>I added the last require after Gerd Moellmann included the others. My
 >>understanding now is that a file only requires another, at compilation,
 >>if it uses a macro defined in that other file.
 >
 > It may also require another file simply to avoid warnings for using
 > undefined functions that are defined in that file.
 >
 > How else would you avoid such warnings?

With (require 'feature) at the top level, since it is needed at runtime.

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 22:05               ` Kevin Rodgers
@ 2004-11-08 23:54                 ` Nick Roberts
  2004-11-09  0:12                   ` Luc Teirlinck
                                     ` (2 more replies)
  2004-11-09 14:11                 ` Kim F. Storm
  1 sibling, 3 replies; 34+ messages in thread
From: Nick Roberts @ 2004-11-08 23:54 UTC (permalink / raw)
  Cc: emacs-devel

 >  >>I added the last require after Gerd Moellmann included the others. My
 >  >>understanding now is that a file only requires another, at compilation,
 >  >>if it uses a macro defined in that other file.
 >  >
 >  > It may also require another file simply to avoid warnings for using
 >  > undefined functions that are defined in that file.
 >  >
 >  > How else would you avoid such warnings?
 > 
 > With (require 'feature) at the top level, since it is needed at runtime.

That's my understanding, too. Furthermore, the compiler warnings are
presumably there to help the developer decide if he needs to use "require".
In the case of tooltip.el, the undefind functions from gud and gdb-ui can only
be invoked by using their debugger modes, so, AFAIK, "require" is not needed
for these features. To use (require 'feature) just to eliminate warnings,
would be the wrong thing to do, I think.

Nick

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 23:54                 ` Nick Roberts
@ 2004-11-09  0:12                   ` Luc Teirlinck
  2004-11-09  0:35                   ` Luc Teirlinck
  2004-11-09  1:27                   ` Luc Teirlinck
  2 siblings, 0 replies; 34+ messages in thread
From: Luc Teirlinck @ 2004-11-09  0:12 UTC (permalink / raw)
  Cc: ihs_4664, emacs-devel

Nick Roberts wrote:

   To use (require 'feature) just to eliminate warnings,
   would be the wrong thing to do, I think.

That is exactly why one should use:

(eval-when-compile (require 'feature))

to eliminate compiler warnings.  (Of course after you checked that it
is really not necessary to require the feature at runtime.)

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 23:54                 ` Nick Roberts
  2004-11-09  0:12                   ` Luc Teirlinck
@ 2004-11-09  0:35                   ` Luc Teirlinck
  2004-11-09  1:27                   ` Luc Teirlinck
  2 siblings, 0 replies; 34+ messages in thread
From: Luc Teirlinck @ 2004-11-09  0:35 UTC (permalink / raw)
  Cc: ihs_4664, emacs-devel

Nick Roberts wrote:

   In the case of tooltip.el, the undefind functions from gud and
   gdb-ui can only be invoked by using their debugger modes, so,
   AFAIK, "require" is not needed for these features.

If gud and gdb-ui are always going to be loaded whenever they have to
be (even after possible code changes in tooltip.el), then I believe
that the best way to avoid warnings is:

(eval-when-compile (require 'feature))

Otherwise, you can use things like `(if (fboundp 'myfun) ...)' or, if
necessary, `with-no-warnings'.  That would avoid silencing future
legitimate warnings. 

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 23:54                 ` Nick Roberts
  2004-11-09  0:12                   ` Luc Teirlinck
  2004-11-09  0:35                   ` Luc Teirlinck
@ 2004-11-09  1:27                   ` Luc Teirlinck
  2 siblings, 0 replies; 34+ messages in thread
From: Luc Teirlinck @ 2004-11-09  1:27 UTC (permalink / raw)
  Cc: ihs_4664, emacs-devel

Sorry, I jumped into a thread again without reading the previous
messages in the thread.  I did not realize that requiring gdb-ui at
compile time gave problems.  If necessary, it is possible to get rid
of the require of gdb-ui (without creating compiler warnings) by using
`(if (fboundp ...) ...)' three times.  If the require of gud yields
problems too, then one needs two additional defvar's.

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 16:59     ` Richard Stallman
@ 2004-11-09  4:28       ` Eli Zaretskii
  2004-11-09 14:20         ` Kim F. Storm
  2004-11-09 21:30         ` Richard Stallman
  0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2004-11-09  4:28 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> CC: nickrob@snap.net.nz, emacs-devel@gnu.org
> Date: Mon, 08 Nov 2004 11:59:42 -0500
> 
> Maybe we should include fringe.c unconditionally, so that defining and
> looking up fringe bitmaps will always work, whether or not Emacs
> can actually display them.

I don't know if fringe.c will compile and link when no X libraries and
no window-system code is present (Kim?).  In any case, the bodies of
some of the functions should probably be conditioned on window-system,
either via #ifdef or a run-time check, if we include fringe.c.  And if
there's already code that tests whether the primitives defined by
fringe.c are fboundp, that code should now be changed to use some
other predicate.

Otherwise, this could be a solution.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 22:05               ` Kevin Rodgers
  2004-11-08 23:54                 ` Nick Roberts
@ 2004-11-09 14:11                 ` Kim F. Storm
  2004-11-09 17:55                   ` Kevin Rodgers
  1 sibling, 1 reply; 34+ messages in thread
From: Kim F. Storm @ 2004-11-09 14:11 UTC (permalink / raw)
  Cc: emacs-devel

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kim F. Storm wrote:
>  > Nick Roberts <nickrob@snap.net.nz> writes:
>  >>I added the last require after Gerd Moellmann included the others. My
>  >>understanding now is that a file only requires another, at compilation,
>  >>if it uses a macro defined in that other file.
>  >
>  > It may also require another file simply to avoid warnings for using
>  > undefined functions that are defined in that file.
>  >
>  > How else would you avoid such warnings?
>
> With (require 'feature) at the top level, since it is needed at runtime.


file a.el has this:
 (require 'b)
 ;;;#autoload
 (defun a-fun1 ()
   (b-fun))
 (defun a-fun2 ()
   t)
 (provide 'a)

file b.el has this:
 (defun b-fun ()
    (a-fun2))
 (provide 'b)

Assuming that b is never used directly, this works fine.


Now, when you byte-compile b.el, you get warning for a-fun2.

So according to your advise, we add
  (require 'a)
to b.el, and compile again with this result:

b.el:1:2:Error: Recursive `require' for feature `a'


What if

(defun a-fun2)

would be a dummy defun for the byte-compiler just like

(defvar a-var)

?


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09  4:28       ` Eli Zaretskii
@ 2004-11-09 14:20         ` Kim F. Storm
  2004-11-10 16:08           ` Richard Stallman
  2004-11-09 21:30         ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Kim F. Storm @ 2004-11-09 14:20 UTC (permalink / raw)
  Cc: nickrob, rms, emacs-devel

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: nickrob@snap.net.nz, emacs-devel@gnu.org
>> Date: Mon, 08 Nov 2004 11:59:42 -0500
>> 
>> Maybe we should include fringe.c unconditionally, so that defining and
>> looking up fringe bitmaps will always work, whether or not Emacs
>> can actually display them.
>
> I don't know if fringe.c will compile and link when no X libraries and
> no window-system code is present (Kim?).  

It will compile as the whole file is conditioned by HAVE_WINDOW_SYSTEM :-)

>                                           In any case, the bodies of
> some of the functions should probably be conditioned on window-system,
> either via #ifdef or a run-time check, if we include fringe.c.  And if
> there's already code that tests whether the primitives defined by
> fringe.c are fboundp, that code should now be changed to use some
> other predicate.
>
> Otherwise, this could be a solution.

IMHO, adding a few dummy definitions to subr.el would be less work.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 14:11                 ` Kim F. Storm
@ 2004-11-09 17:55                   ` Kevin Rodgers
  2004-11-10 16:09                     ` Richard Stallman
  0 siblings, 1 reply; 34+ messages in thread
From: Kevin Rodgers @ 2004-11-09 17:55 UTC (permalink / raw)


Kim F. Storm wrote:
 > Kevin Rodgers <ihs_4664@yahoo.com> writes:
 > > Kim F. Storm wrote:
 > > > How else would you avoid such warnings?
 > >
 > > With (require 'feature) at the top level, since it is needed at 
runtime.
 >
 > file a.el has this:
 >  (require 'b)
 >  ;;;#autoload
 >  (defun a-fun1 ()
 >    (b-fun))
 >  (defun a-fun2 ()
 >    t)
 >  (provide 'a)
 >
 > file b.el has this:
 >  (defun b-fun ()
 >     (a-fun2))
 >  (provide 'b)
 >
 > Assuming that b is never used directly, this works fine.
 >
 >
 > Now, when you byte-compile b.el, you get warning for a-fun2.
 >
 > So according to your advise, we add
 >   (require 'a)
 > to b.el, and compile again with this result:
 >
 > b.el:1:2:Error: Recursive `require' for feature `a'

I think that is why Common Lisp recommends putting (provide 'feature)
first rather than last; but (provide 'feature) is last in Emacs Lisp
files to support the unload-feature command.

 > What if
 >
 > (defun a-fun2)
 >
 > would be a dummy defun for the byte-compiler just like
 >
 > (defvar a-var)
 >
 > ?

That seems natural to me.

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 20:38           ` Nick Roberts
  2004-11-08 21:23             ` Kim F. Storm
@ 2004-11-09 21:29             ` Richard Stallman
  2004-11-10 11:45               ` Nick Roberts
  1 sibling, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2004-11-09 21:29 UTC (permalink / raw)
  Cc: schwab, eliz, emacs-devel

    I added the last require after Gerd Moellmann included the others.

It sounds like you don't actually know of a reason for it.

								       My
    understanding now is that a file only requires another, at compilation,
    if it uses a macro defined in that other file.

    If this is the case, tooltip does not need the last three requires,

Please try deleting them and see what happens.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-08 21:23             ` Kim F. Storm
  2004-11-08 22:05               ` Kevin Rodgers
@ 2004-11-09 21:29               ` Richard Stallman
  2004-11-09 22:58                 ` Luc Teirlinck
  2004-11-09 23:22                 ` Kim F. Storm
  1 sibling, 2 replies; 34+ messages in thread
From: Richard Stallman @ 2004-11-09 21:29 UTC (permalink / raw)
  Cc: schwab, nickrob, eliz, emacs-devel

    It may also require another file simply to avoid warnings for using
    undefined functions that are defined in that file.  

This "solution" causes more trouble the problem it is meant to solve;
please don't use it.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09  4:28       ` Eli Zaretskii
  2004-11-09 14:20         ` Kim F. Storm
@ 2004-11-09 21:30         ` Richard Stallman
  1 sibling, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2004-11-09 21:30 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

    I don't know if fringe.c will compile and link when no X libraries and
    no window-system code is present (Kim?).

I think it can't be too hard to make it compile.  Most of the code is
concerned with constructing and accessing fringe bitmaps, and that doesn't
depend on having a real window system.  If someone just tries compiling
it, you should see soon enough what parts to turn off.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 21:29               ` Richard Stallman
@ 2004-11-09 22:58                 ` Luc Teirlinck
  2004-11-10  0:02                   ` Stefan Monnier
  2004-11-11  3:14                   ` Richard Stallman
  2004-11-09 23:22                 ` Kim F. Storm
  1 sibling, 2 replies; 34+ messages in thread
From: Luc Teirlinck @ 2004-11-09 22:58 UTC (permalink / raw)
  Cc: schwab, nickrob, emacs-devel, eliz, storm

Richard Stallman wrote:

       It may also require another file simply to avoid warnings for using
       undefined functions that are defined in that file.  

   This "solution" causes more trouble the problem it is meant to solve;
   please don't use it.

I do not know whether you are talking about a _run-time_ require or
about the (eval-when-compile (require ...) ...) _in this particular
file_.

If you are talking about (eval-when-compile (require ...) ...) _in
general_ then the following text from `(elisp)Coding Conventions'
which encourages use of this construct to avoid compiler warnings
should be changed:

     Sometimes adding a `require' for another package is useful to
     avoid compilation warnings for variables and functions defined in
     that package.  If you do this, often it is better if the
     `require' acts only at compile time.  Here's how to do that:

          (eval-when-compile
            (require 'foo)
            (defvar bar-baz))


Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 21:29               ` Richard Stallman
  2004-11-09 22:58                 ` Luc Teirlinck
@ 2004-11-09 23:22                 ` Kim F. Storm
  1 sibling, 0 replies; 34+ messages in thread
From: Kim F. Storm @ 2004-11-09 23:22 UTC (permalink / raw)
  Cc: schwab, nickrob, eliz, emacs-devel

Richard Stallman <rms@gnu.org> writes:

>     It may also require another file simply to avoid warnings for using
>     undefined functions that are defined in that file.  
>
> This "solution" causes more trouble the problem it is meant to solve;
> please don't use it.

What about the suggestion to have a "declare only" form of defun:

(defun external-func)

that could be added to a file to avoid compiler warnings?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 22:58                 ` Luc Teirlinck
@ 2004-11-10  0:02                   ` Stefan Monnier
  2004-11-10  0:08                     ` Luc Teirlinck
  2004-11-11  3:14                   ` Richard Stallman
  1 sibling, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2004-11-10  0:02 UTC (permalink / raw)
  Cc: rms, schwab, nickrob, emacs-devel, storm, eliz

>      Sometimes adding a `require' for another package is useful to
>      avoid compilation warnings for variables and functions defined in
>      that package.  If you do this, often it is better if the
>      `require' acts only at compile time.  Here's how to do that:

>           (eval-when-compile
>             (require 'foo)
>             (defvar bar-baz))

At least the (defvar bar-baz) should be removed since it has no effect
inside an eval-when-compile (i.e. it doesn't remove the warning).
The `require' doesn't necessarily remove the warning either, mind you.


        Stefan

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-10  0:02                   ` Stefan Monnier
@ 2004-11-10  0:08                     ` Luc Teirlinck
  0 siblings, 0 replies; 34+ messages in thread
From: Luc Teirlinck @ 2004-11-10  0:08 UTC (permalink / raw)
  Cc: rms, schwab, nickrob, emacs-devel, storm, eliz

Stefan Monnier wrote:

   The `require' doesn't necessarily remove the warning either, mind you.

I which situations not?  I believe that it should work as long as you
use it before the first use of the variables or functions in question.

I agree that the defvar inside the `eval-when-compile' should be removed.

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 21:29             ` Richard Stallman
@ 2004-11-10 11:45               ` Nick Roberts
  0 siblings, 0 replies; 34+ messages in thread
From: Nick Roberts @ 2004-11-10 11:45 UTC (permalink / raw)
  Cc: schwab, eliz, emacs-devel


 >     If this is the case, tooltip does not need the last three requires,
 > 
 > Please try deleting them and see what happens.

I've done this, followed by "make bootstrap". Since I can find no problem,
I've committed this change. I think there are many other files with requires
that, similarly, aren't really needed. Possibly because of what Luc has
pointed out it says in the manual:

> Sometimes adding a `require' for another package is useful to
> avoid compilation warnings for variables and functions defined in
> that package.  If you do this, often it is better if the
> `require' acts only at compile time...

I've also deleted the require for cl. Using this at compile time, presumably
compiles in expansions of the Common Lisp macros for push and pop, rather than
those in subr.el, which might be undesirable.

Nick

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 14:20         ` Kim F. Storm
@ 2004-11-10 16:08           ` Richard Stallman
  0 siblings, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2004-11-10 16:08 UTC (permalink / raw)
  Cc: eliz, nickrob, emacs-devel

    > I don't know if fringe.c will compile and link when no X libraries and
    > no window-system code is present (Kim?).  

    It will compile as the whole file is conditioned by HAVE_WINDOW_SYSTEM :-)

The idea is to make most of the functions work just the same
with or without a window system.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 17:55                   ` Kevin Rodgers
@ 2004-11-10 16:09                     ` Richard Stallman
  0 siblings, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2004-11-10 16:09 UTC (permalink / raw)
  Cc: emacs-devel

     > What if
     >
     > (defun a-fun2)
     >
     > would be a dummy defun for the byte-compiler just like
     >
     > (defvar a-var)

This is ok with me.
I'd much rather use this method than add require calls
for files that we really would rather not load.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: gdb-ui.el assumes images support
  2004-11-09 22:58                 ` Luc Teirlinck
  2004-11-10  0:02                   ` Stefan Monnier
@ 2004-11-11  3:14                   ` Richard Stallman
  1 sibling, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2004-11-11  3:14 UTC (permalink / raw)
  Cc: schwab, nickrob, emacs-devel, eliz, storm

    If you are talking about (eval-when-compile (require ...) ...) _in
    general_ then the following text from `(elisp)Coding Conventions'
    which encourages use of this construct to avoid compiler warnings
    should be changed:

	 Sometimes adding a `require' for another package is useful to
	 avoid compilation warnings for variables and functions defined in
	 that package.  If you do this, often it is better if the
	 `require' acts only at compile time.  Here's how to do that:

	      (eval-when-compile
		(require 'foo)
		(defvar bar-baz))

Thanks for finding this.  I think I will rewrite it not to suggest this.

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2004-11-11  3:14 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-06 17:03 gdb-ui.el assumes images support Eli Zaretskii
2004-11-07  0:23 ` Nick Roberts
2004-11-07  4:48   ` Eli Zaretskii
2004-11-07 10:35     ` Andreas Schwab
2004-11-07 22:12       ` Eli Zaretskii
2004-11-08 10:15         ` Andreas Schwab
2004-11-08 12:11           ` Eli Zaretskii
2004-11-08 16:58         ` Richard Stallman
2004-11-08 20:38           ` Nick Roberts
2004-11-08 21:23             ` Kim F. Storm
2004-11-08 22:05               ` Kevin Rodgers
2004-11-08 23:54                 ` Nick Roberts
2004-11-09  0:12                   ` Luc Teirlinck
2004-11-09  0:35                   ` Luc Teirlinck
2004-11-09  1:27                   ` Luc Teirlinck
2004-11-09 14:11                 ` Kim F. Storm
2004-11-09 17:55                   ` Kevin Rodgers
2004-11-10 16:09                     ` Richard Stallman
2004-11-09 21:29               ` Richard Stallman
2004-11-09 22:58                 ` Luc Teirlinck
2004-11-10  0:02                   ` Stefan Monnier
2004-11-10  0:08                     ` Luc Teirlinck
2004-11-11  3:14                   ` Richard Stallman
2004-11-09 23:22                 ` Kim F. Storm
2004-11-09 21:29             ` Richard Stallman
2004-11-10 11:45               ` Nick Roberts
2004-11-08 16:59     ` Richard Stallman
2004-11-09  4:28       ` Eli Zaretskii
2004-11-09 14:20         ` Kim F. Storm
2004-11-10 16:08           ` Richard Stallman
2004-11-09 21:30         ` Richard Stallman
2004-11-07 18:04 ` Richard Stallman
2004-11-08 12:47   ` Kim F. Storm
2004-11-08 14:55     ` Stefan

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.