(require ...) and file dependencies.

(require ...) and file dependencies.

[Oleksandr Gavenko]

During compilation I got:

  Warning: reference to free variable
  Warning: assignment to free variable

They may fixed by:

  (eval-when-compile
    (defvar ...))

But what to do with:

  Warning: the function `...' is not known to be defined.

I have:

  xxx-mode.el
  xxx-update.el

and both files mix uses of variables and functions. "xxx-mode.el" have

  (require 'xxx-update)

and designed to be loaded by user. So "xxx-update.el" can't use

  (require 'xxx-mode)

or you get:

  Error: Recursive `require' for feature `xxx-mode'

Is that right to use (this is used in CEDET):

  (eval-when-compile
    (require 'xxx-mode))

Seems that proper way to fix issue is by rearranging dependency hierarchy by
breaking dependency cycles, isn't?

I think that I need to move shared definitions from xxx-mode.el into
xxx-core.el:

  xxx-mode.el:
    (require 'xxx-core)
    (require 'xxx-update)

  xxx-update.el:
    (require 'xxx-core)

I check elisp sources for influence:

  cc-vars.el
  cc-defs.el
  cc-mode.el
  
  cedet-devel-load.el

so elisp sources usually organise dependency in acyclic graph and provides
special loaders.

-- 
Best regards!

Re: (require ...) and file dependencies.

[Oleksandr Gavenko]

On 2014-12-28, Oleksandr Gavenko wrote:

> Is that right to use (this is used in CEDET):
>
>   (eval-when-compile
>     (require 'xxx-mode))

My fault - this also leads to "Recursive `require'".

Above trick work only if I move (provide 'xxx-mode) from bottom to top of the
"'xxx-mode.el".

Is that also incorrect way to fix waring when have dependency problems?

-- 
Best regards!

Re: (require ...) and file dependencies.

[Dmitry Gutov]

On 12/28/2014 01:42 AM, Oleksandr Gavenko wrote:

> But what to do with:
>
>    Warning: the function `...' is not known to be defined.
>
> I have:
>
>    xxx-mode.el
>    xxx-update.el
>
> and both files mix uses of variables and functions. "xxx-mode.el" have
>
>    (require 'xxx-update)
>
> and designed to be loaded by user. So "xxx-update.el" can't use
>
>    (require 'xxx-mode)
>
> or you get:
>
>    Error: Recursive `require' for feature `xxx-mode'

You can use `declare-function' in this case. And then make sure than the 
other package is actually loaded at runtime.

> Seems that proper way to fix issue is by rearranging dependency hierarchy by
> breaking dependency cycles, isn't?

That would be even better, of course.

Re: (require ...) and file dependencies.

[Stefan Monnier]

> They may fixed by:
>
>   (eval-when-compile
>     (defvar ...))

No, it's fixed with

    (defvar <foo>)

Siuch (defvar <foo>) declarations (i.e. without an initial value) are
annotations for the *compiler*, so you don't want to pas them to the
`eval'uator (hence you don't want to wrap them in `eval-when-compile').
The fact that they also work when wrapped in `eval-when-compile' is an
accident which might get fixed at any point.

>   Warning: the function `...' is not known to be defined.

For these you have (declare-function ...)

> Is that right to use (this is used in CEDET):
>
>   (eval-when-compile
>     (require 'xxx-mode))

In general, no, this will just change the warnings from "not known to be
defined" to "not known to be defined at run-time".  But if you need it
because the problematic function is actually a macro, then yes, this can
be the right thing to do (tho it won't necessarily fix your recursive
load).

> Seems that proper way to fix issue is by rearranging dependency hierarchy by
> breaking dependency cycles, isn't?

That's would be The Right Thing to do, yes.

> I think that I need to move shared definitions from xxx-mode.el into
> xxx-core.el:

That's one way, yes.  Another is to move the shared definitions to one
of the two files (presumably to xxx-update since xxx-mode is the one
that should require the other).


        Stefan

Re: (require ...) and file dependencies.

[Stefan Monnier]

> Above trick work only if I move (provide 'xxx-mode) from bottom to top of the
> "'xxx-mode.el".
> Is that also incorrect way to fix waring when have dependency problems?

It will make you lose some karma, but it's also a workaround that can do
the trick.


        Stefan

Re: (require ...) and file dependencies.

[Emanuel Berg]

Oleksandr Gavenko <gavenkoa@gmail.com> writes:

> But what to do with: Warning: the function `...' is
> not known to be defined.

Yes, use (require '...) for not only the Emacs stuff
but also everything you do. Put (provide '...) last
and you're all set.

> Seems that proper way to fix issue is by rearranging
> dependency hierarchy by breaking dependency cycles,
> isn't?

You are right, *but*, when you put it that way it
seems like almost some government-backed scientific
endeavor!

It is very simple: just constantly arrange the source
files so that what is similar is close to each other.
E.g., you write A, then you write B, then you write a,
ah, that's close to A, let's put it there, so you have
A, a, and B, you write b - BAM! - time to make two
files: A, a, and B, b.

Just make a habit of doing this constantly: arrange,
break, provide, require.

Don't be afraid to have tons of files, some that might
be very short indeed!

It is not difficult, so I'm not even going to say
"good luck" this time. Or did I...

-- 
underground experts united

Re: (require ...) and file dependencies.

[Emanuel Berg]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> Seems that proper way to fix issue is by
>> rearranging dependency hierarchy by breaking
>> dependency cycles, isn't?
>
> That would be even better, of course.

And more pleasant and rewarding to do, as well. Just
go with the flow, man :)

-- 
underground experts united

Re: (require ...) and file dependencies.

[Oleksandr Gavenko]

On 2014-12-28, Stefan Monnier wrote:

>> They may fixed by:
>>
>>   (eval-when-compile
>>     (defvar ...))
>
> No, it's fixed with
>
>     (defvar <foo>)
>
> Siuch (defvar <foo>) declarations (i.e. without an initial value) are
> annotations for the *compiler*, so you don't want to pas them to the
> `eval'uator (hence you don't want to wrap them in `eval-when-compile').
> The fact that they also work when wrapped in `eval-when-compile' is an
> accident which might get fixed at any point.

Thanks for tips. I found:

>>   (eval-when-compile
>>     (defvar ...))

by grepping some sources. I usually try to check how things done by another
before inventing own style.

Currently Emacs sources have some occurrences of such code (so I send replay
also in private to rise attention). I run:

  ack -C 4 eval-when-compile  # with 4 line context 

and look to `defvar`. Before showing complete list I put weird code, which
seems need to be fixed:

  lisp/progmodes/sql.el
  1391:(eval-when-compile
  1392-  (defvar sql-mode-ansi-font-lock-keywords)
  1393-  (setq sql-mode-ansi-font-lock-keywords nil))

Here strange comment and strange conditional defvar:

  lisp/progmodes/verilog-mode.el
  8407:(eval-when-compile
  8408-  ;; Prevent compile warnings; these are let's, not globals
  8409:  ;; Do not remove the eval-when-compile
  8410-  ;; - we want an error when we are debugging this code if they are refed.
  8411-  (defvar sigs-in)
  8412-  (defvar sigs-inout)
  8413-  (defvar sigs-intf)
    (defvar sigs-out)
    (defvar sigs-out-d)
    (defvar sigs-out-i)
    (defvar sigs-out-unk)
    (defvar sigs-temp)
    ;; These are known to be from other packages and may not be defined
    (defvar diff-command nil)
    (defvar vector-skip-list)
    ;; There are known to be from newer versions of Emacs
    (defvar create-lockfiles))
  10065:(eval-when-compile
  10066-  (if (not (boundp 'indent-pt))
  10067-      (defvar indent-pt nil "Local used by insert-indent")))

I don't understand Gnus magic for XEmacs:

  lisp/gnus/gnus-ml.el
  87:(eval-when-compile
  88-  (when (featurep 'xemacs)
  89-    (defvar gnus-mailing-list-mode-hook)
  90-    (defvar gnus-mailing-list-mode-on-hook)
  91-    (defvar gnus-mailing-list-mode-off-hook)))

  lisp/gnus/gnus-salt.el
  103:(eval-when-compile
  104-  (when (featurep 'xemacs)
  105-    (defvar gnus-pick-mode-on-hook)
  106-    (defvar gnus-pick-mode-off-hook)))
  342:(eval-when-compile
  343-  (when (featurep 'xemacs)
  344-    (defvar gnus-binary-mode-on-hook)
  345-    (defvar gnus-binary-mode-off-hook)))

  lisp/gnus/gnus-dired.el
  89:(eval-when-compile
  90-  (when (featurep 'xemacs)
  91-    (defvar gnus-dired-mode-hook)
  92-    (defvar gnus-dired-mode-on-hook)
  93-    (defvar gnus-dired-mode-off-hook)))

Seems that this can be fixed by anyone with commit right away:

  lisp/org/org.el
  8477:(eval-when-compile
  8478-  (defvar org-property-drawer-re))

  lisp/org/org-colview.el
  752:(eval-when-compile (defvar org-columns-time))

  lisp/printing.el
  1099:(eval-when-compile
  1100-  ;; User Interface --- declared here to avoid compiler warnings
  1101-  (defvar pr-path-style)
  1102-  (defvar pr-auto-region)
  1103-  (defvar pr-menu-char-height)

-- 
Best regards!

Re: (require ...) and file dependencies.

[Oleksandr Gavenko]

On 2014-12-28, Stefan Monnier wrote:

>> They may fixed by:
>>
>>   (eval-when-compile
>>     (defvar ...))
>
> No, it's fixed with
>
>     (defvar <foo>)
>
> Siuch (defvar <foo>) declarations (i.e. without an initial value) are
> annotations for the *compiler*, so you don't want to pas them to the
> `eval'uator (hence you don't want to wrap them in `eval-when-compile').
> The fact that they also work when wrapped in `eval-when-compile' is an
> accident which might get fixed at any point.

I check if (defvar <foo>) pollute `load-history` and it is not!

So any can safely load libraries with fake `(defvar <foo>)` and then load
original library and `<foo>` will refer to place where value or/and doc-string
provided!

Seems that docs have no any direct words about defvar and load-history.

-- 
Best regards!

Re: (require ...) and file dependencies.

[Oleksandr Gavenko]

On 2015-01-03, Emanuel Berg wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>>> Seems that proper way to fix issue is by
>>> rearranging dependency hierarchy by breaking
>>> dependency cycles, isn't?
>>
>> That would be even better, of course.
>
> And more pleasant and rewarding to do, as well. Just
> go with the flow, man :)

I fix compilation warnings and errors in wesnoth-mode.

It have wesnoth-mode.el and wesnoth-update.el (for generating validation
schema and context sensitive completion). wesnoth-update.el uses some core
parsing function from wesnoth-mode.el and author define key binding to
wesnoth-update.el from wesnoth-mode.el...

To fix issues large parts of code must migrate between files and DVCS
blame/annotate history was lost in refactoring.

That limitation I hate in VCS. So you have to store detailed copy/paste info
in commit message or intensively grep and "DVCS update -r rev" to figure out
original place of defun to get know who/when and what fixes done with that
defun.

-- 
Best regards!

Re: (require ...) and file dependencies.

[Emanuel Berg]

Oleksandr Gavenko <gavenkoa@gmail.com> writes:

> That limitation I hate in VCS. So you have to store
> detailed copy/paste info in commit message or
> intensively grep and "DVCS update -r rev" to figure
> out original place of defun to get know who/when and
> what fixes done with that defun.

Aha, for such a project when many people fiddle with
everything, I think my method would bring havoc as the
commits would be huge. Better then to divide the code
once and for all between the programmers and then all
do their part. That will also tell who is programmer,
and who is not...

-- 
underground experts united