bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Nicolas Richard]

Hi,

I cloned the elpa git repo, ran "make externals" and "make", then got:

In toplevel form:
packages/ada-mode/ada-build.el:41:1:Error: Cannot open load file: aucun fichier ou dossier de ce type, wisi-compat-24.2
make[1]: *** [packages/ada-mode/ada-build.elc] Erreur 1
make[1] : on quitte le répertoire « /home/youngfrog/sources/elpa »
make: *** [all-in-place] Erreur 2


I applied the following patch, but probably this is not the right way
since the workaround clearly worked around something. I'm CC-ing Stephen
Leake who committed that code.

diff --git a/packages/wisi/wisi.el b/packages/wisi/wisi.el
index 62302b7..33b71e9 100755
--- a/packages/wisi/wisi.el
+++ b/packages/wisi/wisi.el
@@ -145,11 +145,9 @@
 (require 'cl-lib)
 (require 'wisi-parse)
 
-;; WORKAROUND: for some reason, this condition doesn't work in batch mode!
-;; (when (and (= emacs-major-version 24)
-;; 	   (= emacs-minor-version 2))
-  (require 'wisi-compat-24.2)
-;;)
+(when (and (= emacs-major-version 24)
+	   (= emacs-minor-version 2))
+  (require 'wisi-compat-24.2))
 
 ;;;; lexer
 

-- 
Nico.

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Stephen Leake]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> I cloned the elpa git repo, ran "make externals" and "make", then got:

I get:

packages/ada-mode/ada-build.el:41:1:Error: Cannot open load file: wisi

> In toplevel form:
> packages/ada-mode/ada-build.el:41:1:Error: Cannot open load file:
> aucun fichier ou dossier de ce type, wisi-compat-24.2
> make[1]: *** [packages/ada-mode/ada-build.elc] Erreur 1
> make[1] : on quitte le répertoire « /home/youngfrog/sources/elpa »
> make: *** [all-in-place] Erreur 2

Apparently this make process does not take into account inter-package
dependencies; ada-mode depends on wisi, and both were upgraded this
morning.

Do you have an older version of 'wisi' installed in ~/.emacs.d/elpa/?
That would explain your symptom.

Is there any way to indicate to the make process that it must build wisi
first, and add it to the load path when building ada-mode?

-- 
-- Stephe

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Nicolas Richard]

Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>
>> I cloned the elpa git repo, ran "make externals" and "make", then got:
>
> I get:
>
> packages/ada-mode/ada-build.el:41:1:Error: Cannot open load file: wisi

Perhaps I have mixed the error messages from my different tries ? Not
sure.

Anyway, the error I reported is because wisi-compat did not exist in my
tree (sorry I did not state that clearly). My HEAD was at 0c8e3a1. I
updated my tree and the file now exists so I guess the error has
disappeared. I just tried : indeed, I don't have the error anymore (my
HEAD is 1905244ada36189d940fdf7e40d3498ae8917fed). I'm thus closing this
bug.

>> In toplevel form:
>> packages/ada-mode/ada-build.el:41:1:Error: Cannot open load file:
>> aucun fichier ou dossier de ce type, wisi-compat-24.2
>> make[1]: *** [packages/ada-mode/ada-build.elc] Erreur 1
>> make[1] : on quitte le répertoire « /home/youngfrog/sources/elpa »
>> make: *** [all-in-place] Erreur 2
>
> Apparently this make process does not take into account inter-package
> dependencies; ada-mode depends on wisi, and both were upgraded this
> morning.

The upgrade fixed the problem for me. Thanks.

> Do you have an older version of 'wisi' installed in ~/.emacs.d/elpa/?
> That would explain your symptom.

I don't, and I have a local patch so that ~/.emacs.d/elpa is not used
(see bug#17291) so it should not have interfered.

> Is there any way to indicate to the make process that it must build wisi
> first, and add it to the load path when building ada-mode?

IIUC, it does not necessarily byte-compile wisi first, but since the
build process invokes (package-initialize), wisi should still be
available (uncompiled) at the moment ada-mode is byte-compiled.

-- 
Nico.

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Andreas Schwab]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Is there any way to indicate to the make process that it must build wisi
> first, and add it to the load path when building ada-mode?

Please try this patch:

diff --git a/GNUmakefile b/GNUmakefile
index 2b07767..d47cb43 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -133,7 +133,8 @@ elcs := $(call SET-diff, $(naive_elcs), $(patsubst %.el, %.elc, $(nbc_els)))
 	@$(EMACS) \
 	    --eval "(setq package-directory-list '(\"$(abspath packages)\"))" \
 	    --eval '(package-initialize)' \
-	    -L $(dir $@) -f batch-byte-compile $<
+	    $(patsubst %, -L %, $(filter-out %/cl-lib, $(pkgs))) \
+	    -f batch-byte-compile $<
 
 .PHONY: elcs
 elcs: $(elcs)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Stefan Monnier]

> -	    -L $(dir $@) -f batch-byte-compile $<
> +	    $(patsubst %, -L %, $(filter-out %/cl-lib, $(pkgs))) \
> +	    -f batch-byte-compile $<
 
I'd rather not go there.


        Stefan

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sat, 19 Apr 2014 22:50:10 -0400
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>, 17292@debbugs.gnu.org,
> 	Stephen Leake <stephen_leake@stephe-leake.org>
> 
> > -	    -L $(dir $@) -f batch-byte-compile $<
> > +	    $(patsubst %, -L %, $(filter-out %/cl-lib, $(pkgs))) \
> > +	    -f batch-byte-compile $<
>  
> I'd rather not go there.

Why?  Once you require GNU Make, what's the reason not to use its
facilities?

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Stefan Monnier]

>> > -	    -L $(dir $@) -f batch-byte-compile $<
>> > +	    $(patsubst %, -L %, $(filter-out %/cl-lib, $(pkgs))) \
>> > +	    -f batch-byte-compile $<
>> I'd rather not go there.
> Why?  Once you require GNU Make, what's the reason not to use its
> facilities?

That's not the issue.  The issue is to redo by hand what
package-initialize already does for us.


        Stefan

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Andreas Schwab]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> That's not the issue.  The issue is to redo by hand what
> package-initialize already does for us.

If it did this bug wouldn't exist.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Nicolas Richard]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> That's not the issue.  The issue is to redo by hand what
>> package-initialize already does for us.
>
> If it did this bug wouldn't exist.

The bug I reported was fixed, as in : I don't have a problem anymore
since Stephen Leake updated ada-mode.

OTOH, Stephen reported a problem that he encountered while trying to
reproduce mine. My best guess is that this new problem is related to
#17291 (i.e. "make" in elpa uses the local ~/.emacs.d/elpa) because I
can't reproduce the problem he mentionned.

-- 
Nico.

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Dmitry Gutov]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Is there any way to indicate to the make process that it must build wisi
> first, and add it to the load path when building ada-mode?

Is there a particular reason the build process byte-compiles packages?
They will be compiled upon installation anyway, right?

bug#17292: 24.3.90; ELPA : "make" makes an error compiling ada-build.el

[Stefan Monnier]

> Is there a particular reason the build process byte-compiles packages?
> They will be compiled upon installation anyway, right?

In this scenario, there will be no further "installation" step.


        Stefan