unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Weiner <rsw@gnu.org>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Emacs 25.0.94: Is require failing to define macros and functions at compile time?
Date: Wed, 29 Jun 2016 10:55:22 -0400	[thread overview]
Message-ID: <CA+OMD9gsA-HkRLURk0eusNeo5_Yg_znkrEN0YG1x0imHgGRWhA@mail.gmail.com> (raw)

I have been seeing a number of problems with byte-compiling the
Hyperbole package due to require statements (probably within
byte-compiled files) not defining certain macros and functions needed
during the compilation of the file with the require in it.  If the
required file is named F, then (require 'F) is insufficient but
(eval-when-compile (load "F.el")) works  (a load of "F" does not
always work), so I am forced to add these eval-when-compile statements
to the code.

Has anyone seen anything similar?  Most of the time the problem is
with a macro definition not be defined and therefore a macro expansion
fails, but sometimes I get undefined functions when I can see the
function is defined within the required file and I know that the path
of the file is in load-path at compile time.  Sometimes the problem is
with recursive requires.

Has anyone seen anything similar?

Isn't require supposed to be sufficient to define both macros and
functions at compile time for a client library?

Here is a recent example from Hyperbole:

When compiling hact.el, I get:
In end of data:
hact.el:322:1:Warning: the following functions are not known to be defined:
    hhist:add

At the top of hact.el is:

(mapc 'require '(hhist set))

In hhist.el is:

(defun hhist:add (elt) ...)

Something is not happening at byte-compile time but why and what is the problem?

Bob



             reply	other threads:[~2016-06-29 14:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-29 14:55 Robert Weiner [this message]
2016-06-29 15:14 ` Emacs 25.0.94: Is require failing to define macros and functions at compile time? Clément Pit--Claudel
2016-06-29 15:44   ` Robert Weiner
2016-06-29 19:06     ` Davis Herring
2016-06-29 19:59       ` Drew Adams
2016-06-29 20:34         ` Robert Weiner
2016-06-29 20:59           ` Drew Adams
2016-06-29 21:04           ` John Mastro
2016-06-30  0:09           ` Herring, Davis
2016-06-30  5:56             ` Robert Weiner
2016-06-29 15:16 ` Drew Adams
2016-06-29 22:03   ` Michael Heerdegen
2016-06-29 22:09     ` Robert Weiner
2016-06-29 22:27       ` Michael Heerdegen
2016-06-29 22:42         ` Drew Adams
2016-06-29 23:14           ` Robert Weiner
2016-06-29 22:07 ` Michael Heerdegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+OMD9gsA-HkRLURk0eusNeo5_Yg_znkrEN0YG1x0imHgGRWhA@mail.gmail.com \
    --to=rsw@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rswgnu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).